[yt-dev] proposed change to development process

Fri Sep 11 09:31:20 PDT 2015

Having a post-commit hook that calls out to something on fido that updates
bookmarks after pull requests get merged would be helpful.

Of course it would be nice if bitbucket added a UI for this but I'm not
holding my breath.

On Friday, September 11, 2015, Kacper Kowalik <xarthisius.kk at gmail.com>
wrote:

> On 09/11/2015 10:29 AM, Matthew Turk wrote:
> > Hi Britton,
> >
> > I've thought through a bit more, and I'm coming around to having multiple
> > heads.  If each one had a feature name, and we didn't get too many
> (i.e., a
> > h-yt-dra haha) then perhaps this would be a fine situation.  Avoiding PRs
> > between repos means consolidating code review, which is a positive thing,
> > as well.  By focusing on *features* rather than the blanked
> "experimental"
> > we would be in a better situation to deal with situations like this, we
> > could still do feature work, and also preserve stability.
>
> Hi all,
> is there something we could do code-wise to make such workflow more
> user-friendly? What are the main "pain" points?
>
> The idea of cursed-based UI for issuing / viewing / editting PRs has
> been on my mind for quite sometime, but I haven't had enough motivation
> to do it...
>
> One semi-related thing I'd like to mention/remind of: there's no need
> for making "fork of forks" of yt repo. Assuming you want to
> collaborately work on already issued PR, you can easily pull it:
>
> hg bbprs -p PRNUMBER
>
> Then add your changes and issue PR with them back to somebody's fork:
>
> hg bbnewpr -t "PR title" -d "PR description" -r tip -n somebody/yt
>
> All this ^^ and other goodies are available in hgbb[1]
> Cheers,
> Kacper
>
> [1] https://bitbucket.org/MatthewTurk/hgbb
>
> > -Matt
> >
> > On Thu, Sep 10, 2015 at 1:52 PM, Britton Smith <brittonsmith at gmail.com
> <javascript:;>>
> > 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 <javascript:;>
> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > yt-dev mailing list
> > yt-dev at lists.spacepope.org <javascript:;>
> > 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/20150911/6032deb1/attachment.htm>