[darcs-users] 'submitted' branch

[Eric Kow]

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:kowey at jabber.fr (Jabber or Google Talk only)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20100914/c847e7d8/attachment-0001.pgp>