<div dir="ltr">Hi Matt,<div><br><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>So I guess "multiple heads" even with multiple bookmarks is off the table now, if I read the rest of the thread correctly? If so, can we figure out a way to allow experimental stuff into "yt" and then move most folks onto "stable"?</div></div></blockquote><div><br></div><div>By my count, Nathan was relenting somewhat under the weight of my walls of text and Cameron was on board despite some concerns. What are your thoughts on having multiple development heads?</div><div><br></div><div>Britton</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Sep 10, 2015 at 1:52 PM, Britton Smith <span dir="ltr"><<a href="mailto:brittonsmith@gmail.com" target="_blank">brittonsmith@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div>Hi everyone,</div><div><br></div><div>I had some ideas for improving the yt development process that I</div><div>wanted to run by everyone. This can be discussed further at our</div><div>upcoming team meeting and if people are in favor, I will issue a pull</div><div>request to the relevant YTEP.</div><div><br></div><div>STATEMENT OF PROBLEM</div><div>Currently, development proceeds roughly as follows. The two main</div><div>active branches within the central yt repository are <b>yt</b> and <b>stable</b>.</div><div>The tip of <b>stable</b> is the latest release and the <b>yt</b> branch is the de</div><div>facto "development version" of the code. Until recently, we have not</div><div>been very good at regularly scheduled minor releases and so the <b>stable</b></div><div>branch sits for quite some time with many bugs that are fixed within</div><div>the development branch. This effectively makes <b>stable</b> unusable and</div><div>pushes most users to the <b>yt</b> branch.</div><div><br></div><div>When new features are developed, pull requests are issued to the</div><div>single head of the <b>yt</b> branch. Because this is the version most people</div><div>are actually using, the current policy is to not allow PR with new</div><div>functionality to be accepted until they are 100% ready (full</div><div>functionality, tests, docs, etc). As we have already seen, this makes</div><div>collaborative development very cumbersome, as it requires people to</div><div>create forks of the fork from which the PR originates. They then must</div><div>issue PRs to that fork after which time the original PR is updated.</div><div>The current volume render refactor is the perfect example of this.</div><div><br></div><div>PROPOSED SOLUTION</div><div>Before I lay out the proposed solution, I want to list a number of</div><div>recent developments that I think will make this possible:</div><div>1. Nathan's new script for backporting changes now keeps <b>stable</b> and <b>yt</b></div><div> synced on bugfixes.</div><div>2. We have returned to doing minor releases containing only bugfixes,</div><div> thanks again to Nathan's hard work. This and point 1 means that</div><div> users are once again safe to be on <b>stable</b>, and now <i>should</i> be there</div><div> most of the time.</div><div>3. Bitbucket now supports bookmarks, meaning that PRs can be issued to</div><div> specific bookmarks instead of to branches or heads named only by the</div><div> changeset hash.</div><div>4. The weekly PR triage hangouts are making it easier to process PRs</div><div> and also providing a place to strategize getting larger PRs</div><div> accepted. Thanks to Hilary for keeping this going.</div><div><br></div><div>With the above in mind, I propose the following:</div><div>1. Create a "development" bookmark to sit at the tip of the <b>yt</b></div><div> branch. All PRs containing relatively small new features are</div><div> issued to this. The requirements for acceptance remain the same:</div><div> PRs accepted to "development" must contain all intended</div><div> functionality and be fully documented. This allows the</div><div> "development" bookmark to be defined explicitly as everything that</div><div> will be included in the next major release.</div><div>2. Large new features should have a corresponding YTEP that has been</div><div> accepted. After the YTEP has been accepted, a PR should be issued</div><div> to the <b>yt</b> branch. After some initial discussion, this PR is pulled</div><div> into the main yt repo with a bookmark named after the feature.</div><div> Once this has happened, developers can now issue new PRs</div><div> specifically to this bookmark. This is effectively what we have</div><div> now with the volume render work in the "experimental" bookmark,</div><div> only we would rename the bookmark to something like "vr-refactor".</div><div> As with PRs issued directly to "development", only after the new</div><div> feature is 100% ready shall it be merged into the "development"</div><div> bookmark.</div><div>3. We continue to make use of the PR triage hangouts to establish when</div><div> large features are ready to be merged.</div><div><br></div><div>I believe this will have the following benefits:</div><div>1. Large, new features can be developed collaboratively without the</div><div> need for forks of forks of forks.</div><div>2. New, underdevelopment features are more accessible to the larger</div><div> community by simply updating to named bookmarks from the main repo</div><div> (no need for "just pull these changes from my fork").</div><div>3. The "development" branch is preserved as a place only for</div><div> ready-to-be-released features (i.e., polished and documented).</div><div><br></div><div><br></div><div>All told, this is really just a small tweak on our current process.</div><div>Please comment with any thoughts, or even a +/-1 if your feelings can</div><div>be summed up thusly.</div><span><font color="#888888"><div><br></div><div>Britton</div></font></span></div></div>
<br></div></div><span class="">_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
<br></span></blockquote></div><br></div>
<br>_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
<br></blockquote></div><br></div></div></div></div>