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