<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Just my two cents, but I agree with Andrew's remarks about how having multiple heads has definitely complicated the workflow and has resulted in some unnecessary confusion and accidental merges. I'm -1 on multiple heads.<br><br><span style="font-size: 13pt; background-color: rgba(255, 255, 255, 0);">John ZuHone</span><br><div><span style="background-color: rgba(255, 255, 255, 0);">Kavli Center for Astrophysics and Space Research<br>Massachusetts Institute of Technology<br><a href="x-apple-data-detectors://0" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="0">77 Massachusetts Ave.</a>, 37-582G<br><a href="x-apple-data-detectors://1/0" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="1/0">Cambridge, MA 02139</a><br>(w) <a href="tel:617-253-2354" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="1/1">617-253-2354</a><br>(m) <a href="tel:781-708-5004" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="1/2">781-708-5004</a><br><a href="mailto:jzuhone@space.mit.edu" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="1/3">jzuhone@space.mit.edu</a><br><a href="mailto:jzuhone@gmail.com" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="2">jzuhone@gmail.com</a><br><a href="http://www.jzuhone.com/" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="3">http://www.jzuhone.com</a></span><br style="font-family: UICTFontTextStyleBody; -webkit-text-size-adjust: auto;"></div></div><div><br>On Sep 10, 2015, at 5:10 PM, Britton Smith <<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><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>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>yt-dev mailing list</span><br><span><a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a></span><br><span><a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a></span><br></div></blockquote></body></html>