[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 <[email protected]> > Date: 3 June 2011 15:19:41 GMT+01:00 > To: Bayard Bell <[email protected]> > Cc: Dan McDonald <[email protected]>, Jason King <[email protected]> > 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
_______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
