Thanks for the summary, Ganesh. I'd like to get a feel for how much consensus we have on this idea. So far Ganesh, Petr and Eric seem to think it's a good approach.
Florent and Reinier, as active reviewers, do you have opinions to contribute about doing something like this in principle? How about Jason as a sort of reviewer emeritus (good ol' Day Job)? On Sun, Sep 12, 2010 at 20:28:51 +0100, Ganesh Sittampalam wrote: > People would submit new work against 'submited' rather than against > HEAD. In turn, this would mean that patches that had landed in > 'submitted' would not be amend-recorded or unpulled. Instead follow > up patches, perhaps even a rollback, would have to be used. Basically we would be paying this price - harder to cherry pick (more dependencies) - dirtier history (more follow-ups/rollbacks) but keeping - all patches reviewed with equivalent thoroughness to today and gaining - less confusion about patch versions (fewer amends) - fewer conflicts - easier to do fast-patch-production - possibility of doing two-tier review (more people can push to submitted than reviewed; tiers enforced by convention and "we're all grown ups here" common sense, not technology) We could also adopt the perspective that making it harder to cherry pick is a good thing because it forces us to confront the demon of cherry picking not actually being very useful in practice. That is, if we put ourselves in a sort of real world situation that doesn't make cherry picking easy and it's *still* very useful, then we can be even more confident about Darcs. Good way to test the darcs idea, perhaps. [That said, we already get this with the current release branches, so it'd just be more of the same] Submitted vs reviewed --------------------- OK so the rest of this is just implementation detail once we all get some consensus about having a two branch reviewed/submitted system in principle. If we're going to bat these sorts of ideas back and forth, perhaps for clarity we talk about these two branches as 'submitted' and 'reviewed' and only talk about HEAD as a pointer. The reason I bring this up is because this morning, it occurred to me that if people just do what comes naturally, darcs get --lazy http://darcs.net # hack-hack-hack darcs send they would be typically sending against the reviewed branch and not the submitted one. Is it acceptable to have lots of patches sent against reviewed and some patches sent against submitted? Or do we try to physically arrange things so that the default action is to send to submitted? Variant: make HEAD submitted and create a 'reviewed' branch? ------------------------------------------------------------ At the risk of bikeshedding, one variant of physically arrange things would be for HEAD may be to make the submitted branch primary and the reviewed branch secondary. To reduce branch proliferation, we could even make the reviewed branch just a very early release branch cut. In a hypothetical scenario: 2011-06 - FREEZE! RM takes over branch-2.8 - Cut branch-2.10 - Symlink branch-2.10 to 'reviewed' [this way, people can just push to reviewed without having to think about which is the right branch to push against] 2011-12 - FREEZE! RM takes over branch-2.10 - Cut branch-2.12 - Symlink branch-2.12 to 'reviewed' One nice thing about this variant is that we retain a fairly simple story. During peace time 1. hacker: grab http://darcs.net 2. darcs send 3. reviewer A: download bundle from tracker 4. darcs get http://darcs.net 5. darcs apply 6. sanity check then push to http://darcs.net 7. reviewer B: download from tracker 8. darcs get http://darcs.net/reviewed 9. darcs pull --bundle foo.dpatch http://darcs.net 10. review and push [goes to reviewed] Hacker and reviewer A could be the same person. During review time, we'd keep the same general workflow, but hacker could alternatively send against the release branch, and reviewer B could also double-push, both to submitted and to reviewed. I'm a bit hesitant about this variant because it exposes users to unreviewed code. Maybe it's simpler for sending against reviewed to be the default and for sending against submitted to be just possible? > It seems like a 'darcs pull --bundle <foo.dpatch> <some repo>' command > would be nice here. It would take the patch names from foo.dpatch, but > ignore the contents, and pull the patches from <some repo> instead. I would suggest that Petr implement a pull --bundle (since he'd be a good user of the submitted branch if we went this route). Florent had a more general mechanism, but one which sounds harder to implement. What do you think, Florent? From a UI Skeptic point of view, should we, just implement pull --bundle for expediency now, and worry about the 'in' matcher later? -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> For a faster response, try +44 (0)1273 64 2905 or xmpp:ko...@jabber.fr (Jabber or Google Talk only)
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
