[darcs-devel] how can Darcs dev be more agile ?

Florent Becker florent.becker at ens-lyon.org
Fri May 11 06:59:04 UTC 2012


Hi Michael,

Michael Hendricks <michael <at> ndrix.org> writes:
> Here are some suggestions that have been on my mind for a while:
> 

I agree with you on finding the process daunting, but I disagree on some of
your proposed solutions, though it's probably because I fail to understand
some crucial part(s). 

> eliminate the issue tracker

Why would you want to do that? I'm not sure I follow you. Can you explain
how it's an obstacle?

> rename "screened" to "public".  Any "darcs send" patches that compile (pass
tests?) are automatically committed here.  public is subject to being wiped
out and replaced with a fresh copy of reviewed as often as we deem necessary

Why not. We can try that, though on the other hand, it can be intimidating.
There certainly needs to be an opt-out out of that (a way to make your
patches visible to the team but disabled by default).

> code review
> 
> if a patch needs no further work, a core developer pulls it directly from
> public into reviewed
> if a patch needs minor polish, he commits a fix to public and pulls
> into reviewed
> 
> if a patch needs more polish/reviewing, a core developer forks reviewed
> making a topic branch to which anyone can commit. he pushes relevant
> patches from public to this topic branch. he might push a patch
> containing TODO comments with his code review suggestions. when the
> branch is polished, it's pulled into reviewed
> 

These three suggestions make me think they'll be more work for core developers
for little gain for occasional developers. 1 and 2 are already what
happens/should happen, except we've been lagging. Can you state what problem 3
is supposed to solve?

I think we should have darcs send to the tracker open a public branch, which
would be treated as a "floating pull request".


> define "core developer" as anyone whose patch makes it to the reviewed
> repository (darcs show authors)

I'm not sure I'm quite ready for that. Because of testing/reviewing/pulling,
I'm practically giving unvetted root access to my machine and some other to
 the "core developers", so I'd rather have that group not be too open.

> host darcs.net website directly off content in reviewed
> 
Yes! I think it should be all in the wiki, using theming and some permissions
to distinguish proper wiki from main site.

> Much of this assumes infrastructure which doesn't exist.  It'd be cool if we
> could use darcsden for some of these steps.  We currently have a focus on
> improving darcs hosting.  Eating our own dog food should help with that.

Yes on darcsden. Do you have precise infrastructure needs in mind? I see:
-Auto-adding to core-developers (with which I disagree)
-Auto-pushing to screened, which we partially have
-Migrating the website out of the repo (strongly agree)

Friendly,

Florent




More information about the darcs-devel mailing list