[yt-dev] proposed change to development process

[Britton Smith]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20150910/eb42484c/attachment.html>