<div dir="ltr">As a first point, I think it's good that we're having this discussion in general. Thanks to everyone for the civil dialog, as it just makes our community stronger.<div><br></div><div>So it seems like most people don't want to have multiple heads in the dev branch? I'm still not entirely convinced that this is bad as long as the merges to the non-main dev head are taking place during the PR triage when one of the members can assure that the tip (or experimental head) is pointing to the right changeset, but people seem really opposed to this. <br><div><br></div><div>As for big PRs getting merged directly into the main dev branch, I guess I still have some reservations. Basically what we're saying is that once a feature goes into the main dev head, it *will* be included in the next major release, and we have to block on that release until its reached the agreed upon level of "doneness". But the problem with this is, different features merged in will be "done" at different times, so maybe feature A is done and its author really wants to get it out to stable, but feature B is not yet done and its author needs to go on vacation or doesn't have time to write docs for it or something. What do we do then? Also, we've had situations in the past with pressure to get releases out that were for reasons other than the development cycle (e.g. jobs, personal, etc.), which is totally understandable, but this leaves us with no other choice than to release all of the features instead of picking which one we release. Big pushes like this are usually when strife occurs in our community. Having multiple heads avoids this clash.</div><div><br></div><div>I agree with Matt that API stability is a main concern about merging something into dev. But once something goes into dev, there are going to be a lot of "users" of it, and to have the API still open to modifications is going to mess with a lot of people's scripts. So I think in order for a PR to get merged into the main dev head, the *doneness* of the functionality should be such that the API is stable (with Matt's caveat that if it really has to change, then it really has to). This API stable rule will help prevent a lot of problems with users getting frustrated down the road. But perhaps it takes a lot of collaborative work (ie forks of forks) before one can get to a stable API before merging into the single dev head model. With multiple heads, this is more easily avoided.</div><div><br></div><div>Lastly, I think at minimum, there needs to be some minimum docs description (docstrings and a simple recipe) included when major work goes into the single-head dev branch, for the simple reason that the other developers need to know how to use the functionality to be able to test it and contribute to it. I think it is unrealistic for the other developers to have to read through the entirety of the new code to understand how to use the functionality once it is in dev. I know this opinion is controversial in our group, but I really think it is important for fostering collaborative development with each other.</div><div><br></div><div>Cameron</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 10, 2015 at 3:29 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I think identifying the criteria for "doneness" is a way to treat the problem, not the symptom. I think much of the problem here is in deciding when a feature can go in to a branch or line of development that is pre-release, but somewhere above "totally unfinished."</div><div><br></div><div>The biggest issue may be related to API stability. I do not think that we can make a hard and fast rule, but if we were able to identify that "We expect no further API breakages, but will do so if necessary as decided through peer review" would that be enough for major features to land in the "yt" branch? I do not think we can expect full documentation, but having this compromise may help increase visibility, improve the overall testing of new features (by putting them in a main line of development) and also ensure that they aren't *so* broken. By this standard, we would not merge VR refactor in yet, but it would be clearer how to do so.</div><div><br></div><div>-Matt</div><div><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 10, 2015 at 5:18 PM, Nathan Goldbaum <span dir="ltr"><<a href="mailto:nathan12343@gmail.com" target="_blank">nathan12343@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Sep 10, 2015 at 4:17 PM, Britton Smith <span dir="ltr"><<a href="mailto:brittonsmith@gmail.com" target="_blank">brittonsmith@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Andrew,<div><br></div><div>Have we continued to have problems with PRs being issued to the wrong head now that Bitbucket tags the heads with bookmarks? If so, then maybe that's the end, but I was under the impression that that had taken care of this.</div></div></blockquote><div><br></div></span><div>I don't think it has come up since that hapenned, but we haven't been in a situation where the "experimental" bookmark was the tip of the yt branch for more than a day or two.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>As far as allowing development to take place in a single dev head, I am worried about ending up in the situation where many new features in there are ready to go and some are not. If development has continued over multiple PRs on different features, will it still be possible to pick out only the features that are ready? If so, then I guess that's that, but if not, then I am very wary of this.</div></div></blockquote><div><br></div></span><div>In practice how would this problem work? Right now we have an experimental bookmark including both unstructured mesh support and the volume rendering refactor. Since unstructured mesh support depends on the VR refactor, we can't release that it without also releasing the VR refactor. In principle we could release the VR refactor without unstructured mesh support, but I think we all agree that 3.3 should probably include both features.</div><div><br></div><div>I think merging a new feature into a single-headed yt branch implicitly means that that the feature will be "done" in time for the next major release. If we have more than one work-in-progress features due for the next major release, then the release is blocked on all of them. As a community we need to be careful to not merge in features if we're not prepared to block the release on them until they are done.</div><div> </div><div>Maybe as a way to move this discussion forward, since there seems to be two main perspectives, is there any way at all for us to compromise? I'm not sure there is, since some of us think it's ok to have work-in-progress features in the dev branch while they're still not fully baked, while others strongly object. Maybe we could have a discussion about what level of "doneness" a new feature needs to have before it can be merged in? Right now the level of acceptable "doneness" is quite high, and maybe it can be relaxed a bit while still keeping everyone happy.</div><div><div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><font color="#888888"><div><br></div><div>Britton</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 10, 2015 at 4:59 PM, Andrew Myers <span dir="ltr"><<a href="mailto:atmyers2@gmail.com" target="_blank">atmyers2@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I just want to chime in to say I agree with Nathan and Matt re: allowing more active development on the yt branch. Ideally, I think there should be two branches (stable and yt) with one head each, with the yt branch being the "development" version of the code. Most users would be on the stable branch, and more active users / developers would be on the development branch. Having multiple heads / bookmarks on the yt branch makes for a more complicated development process (as evidenced by the fact that none of us can remember how it works in this very email chain ;) ), which can be discouraging for new developers. Since creating the experimental bookmark for the scene refactor, we've already had PRs accidently made and merged into the wrong head, and it's created more work for Kacper in keeping the CI working smoothly. <div><br></div><div>I appreciate the concerns about release deadlines creating pressure to release under-documented and under-tested code. However, and as others have stated, with Nathan's backport script, we can now do bugfix releases as often as needed, which removes some (most? all?) of that pressure. <div><br></div><div>Additionally, I agree that in practice, most of the serious testing of new features is going to be done after the code gets merged, and the community of yt developers / active users who use the development version of the code get their hands on it. Doing that merge sooner rather than later will result in an overall faster timeline to stable code.</div><div><br></div><div>To be clear, I think Britton's proposal is a definite improvement over the "forks of forks" model, but I think an even simpler development process with only one head on the main yt branch would be more productive in the long run.</div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 10, 2015 at 1:23 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Britton,<div><br></div><div>I was going to reply, broadly in support of everything you suggested, until I saw the other emails. It looks like I missed my opportunity.</div><div><br></div><div>In general, I would like to see more experimental development in the main yt repo; I think with the backporting script, as you suggest, we now have a good reason for people to use "stable" instead of the main development branch.</div><div><br></div><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><div class="gmail_extra"><br><div class="gmail_quote"><div><div>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><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>_______________________________________________<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" 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></blockquote></div><br></div>
</div></div><br>_______________________________________________<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></blockquote></div><br></div>
</div></div><br>_______________________________________________<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></blockquote></div></div></div><br></div></div>
<br>_______________________________________________<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></blockquote></div><br></div></div></div></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><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Cameron Hummels<div><span style="font-size:12.8000001907349px">NSF Postdoctoral Fellow</span></div><div><span style="font-size:12.8000001907349px">Department of Astronomy</span></div><div><span style="font-size:12.8000001907349px">California Institute of Technology</span><br></div><div><a href="http://chummels.org" style="font-size:12.8000001907349px" target="_blank">http://chummels.org</a><br></div></div></div></div>
</div>