[oi-dev] Fwd: project gates, code management practices

[Bayard Bell]

[danmcd CC'ed for follow-up questions; apparently I do not know how to operate my MUA or need to find myself a new one]

Since project gates (aka feature branches) have featured in our recently commenced discussion of SCM, here's what I got back from asking danmcd about the mechanics and process of what we're doing in the IKE project gate.

Begin forwarded message:

> From: Dan McDonald <danmcd at nexenta.com>
> Date: 3 June 2011 15:19:41 GMT+01:00
> To: Bayard Bell <buffer.g.overflow at gmail.com>
> Cc: Dan McDonald <danmcd at nexenta.com>, Jason King <jason.brian.king at gmail.com>
> Subject: Re: project gates, code management practices
> 
>> I think I get the rationale for having a separate project gate for IKE:
>> you've got an ongoing series of extensive changes to manage, and you want
>> effectively to branch and then manage a merge only when the branch is fully
>> baked. The questions that come up are largely in terms of process and
>> mechanics.
> 
> Understood.  And I'm glad you asked me about this.
> 
>> DeanoC suggested bookmarks as a way to do this, and I don't know bookmarks
>> and don't have an answer on that. I don't know what experience you may have
>> of them, but I thought I'd ask how you've gone about tracking Illumos
>> changes and your sense of what the resulting overhead looks like, such that
>> other options can be researched and compared to that. When it comes time to
>> merge, what is that process expected to look like? Once the coding is done
>> and the product tested using the project gate, do the changes get broken
>> down into pieces that can be committed incrementally back into the main
>> branch and can be reasonably digested as webrevs?
>> 
>> Also, as far as having multiple people working on a project gate, jbk had
>> already suggested that we need some protocols for how we coordinate changes
>> between individual workspaces and the project parent. Neither jbk nor I
>> have experience with that kind of team workflow, so we were hoping to get
>> feedback from danmcd about how to do this properly and leverage what's
>> already in the toolset. Similarly, I'm curious how much we need to document
>> as issues as we work through the code so that decisions can be understood
>> to someone else who has to evaluate the code for merging. danmcd has some
>> apparent experience with this in terms of pulling in Joyent IP patches and
>> needing to document their underlying logic to provide context to whoever's
>> doing the webrev.
> 
> For a larger project (like this), I've run it as follows:
> 
> 	1.) Find a gatekeeper.  For project I led, I usually assumed this
> 	    role.  The gatekeeper will:
> 
> 		- Do pulls from upstream.  Inside Sun/Oracle, I did them
>                  nightly.  Your mileage may vary.
> 
> 		- Do merges and resolves every morning if need be, BUT NOT
>                  "hg recommit".  You want all of the merge-turds until you
>                  are ready to push the whole ball of wax back.
> 
> 		- Generate fresh webrevs post-merge.
> 
> 		- Do nightly builds.  I always timed this to start 2-3 hours
>                  prior to the next day's pull.  Your nightly build archives
>                  will lag behind the gate by a day, which isn't bad if you
>                  discover a problem later.
> 
> 	2.) Most pushes, save the trivial, into the main project gate must
> 	    have at least one reviewer from the team.  This usually was
> 	    quick, and always e-mail based (for the record).  Short timeouts
> 	    were used to keep the overwhelmed from holding things up.
> 	    (E.g. Paul and I would check each other's work while Mark was
> 	    buried in his own change.)
> 
> 	3.) Once we were ready to go, we would actually unleash the whole
> 	    thing at once for review.  If we needed to break things down,
> 	    we'd do so at the gate or local-workspace level ("Oh, save that
> 	    for the next phase, it won't go in the project gate for now.").
> 
> 	4.) Prior to actual integration, we'd do an "hg recommit" to remove
> 	    all of the merge turds and push it back as one changeset.
> 
> 	5.) If we found bugs or bits that were useful to the upstream gate
> 	    (illumos in this case), we might clone upstream and fix those
> 	    specific bugs/bits in the main gate first.  (E.g. My fixing of
> 	    regular-ACQUIRE may be suitable as a fix to Illumos itself.)
> 
> The archived flow of e-mail will help here immensely, IMHO.
> 
> Hope this helps,
> Dan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20110623/5bbc5238/attachment-0001.html>