[yt-dev] proposed change to development process

[Britton Smith]

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