[yt-dev] proposed change to development process

John ZuHone jzuhone at gmail.com
Thu Sep 10 14:13:31 PDT 2015


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.

John ZuHone
Kavli Center for Astrophysics and Space Research
Massachusetts Institute of Technology
77 Massachusetts Ave., 37-582G
Cambridge, MA 02139
(w) 617-253-2354
(m) 781-708-5004
jzuhone at space.mit.edu
jzuhone at gmail.com
http://www.jzuhone.com

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


More information about the yt-dev mailing list