Hi everyone,I had some ideas for improving the yt development process that Iwanted to run by everyone. This can be discussed further at ourupcoming team meeting and if people are in favor, I will issue a pullrequest to the relevant YTEP.STATEMENT OF PROBLEMCurrently, development proceeds roughly as follows. The two mainactive branches within the central yt repository are yt and stable.The tip of stable is the latest release and the yt branch is the defacto "development version" of the code. Until recently, we have notbeen very good at regularly scheduled minor releases and so the stablebranch sits for quite some time with many bugs that are fixed withinthe development branch. This effectively makes stable unusable andpushes most users to the yt branch.When new features are developed, pull requests are issued to thesingle head of the yt branch. Because this is the version most peopleare actually using, the current policy is to not allow PR with newfunctionality to be accepted until they are 100% ready (fullfunctionality, tests, docs, etc). As we have already seen, this makescollaborative development very cumbersome, as it requires people tocreate forks of the fork from which the PR originates. They then mustissue PRs to that fork after which time the original PR is updated.The current volume render refactor is the perfect example of this.PROPOSED SOLUTIONBefore I lay out the proposed solution, I want to list a number ofrecent developments that I think will make this possible:1. Nathan's new script for backporting changes now keeps stable and ytsynced 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 thatusers are once again safe to be on stable, and now should be theremost of the time.3. Bitbucket now supports bookmarks, meaning that PRs can be issued tospecific bookmarks instead of to branches or heads named only by thechangeset hash.4. The weekly PR triage hangouts are making it easier to process PRsand also providing a place to strategize getting larger PRsaccepted. 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 ytbranch. All PRs containing relatively small new features areissued to this. The requirements for acceptance remain the same:PRs accepted to "development" must contain all intendedfunctionality and be fully documented. This allows the"development" bookmark to be defined explicitly as everything thatwill be included in the next major release.2. Large new features should have a corresponding YTEP that has beenaccepted. After the YTEP has been accepted, a PR should be issuedto the yt branch. After some initial discussion, this PR is pulledinto the main yt repo with a bookmark named after the feature.Once this has happened, developers can now issue new PRsspecifically to this bookmark. This is effectively what we havenow 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 newfeature is 100% ready shall it be merged into the "development"bookmark.3. We continue to make use of the PR triage hangouts to establish whenlarge features are ready to be merged.I believe this will have the following benefits:1. Large, new features can be developed collaboratively without theneed for forks of forks of forks.2. New, underdevelopment features are more accessible to the largercommunity 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 forready-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 canbe summed up thusly.Britton
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org