[yt-dev] Proposed change to development practices

Fri Jan 16 16:00:41 PST 2015

On Wed, Jan 14, 2015 at 6:36 AM, Cameron Hummels <chummels at gmail.com> wrote:

> I like this idea, but I have a few comments.
>
> It seems like the boundary between a bugfix and new functionality is
> pretty blurred in most instances.  Few are the bugfixes which are just
> correcting typos or a single line of code, and oftentimes in order to fix a
> bug fully, a significant amount of new code needs to go in.  So I have my
> concerns about how to deal with making the decision when something should
> go in stable or in yt branches.
>

This will be tough.  I think in many cases it will be clear.

When it's blurry I think it will be up to the PR reviewers.

> Also, who will be responsible for applying code from stable to the yt
> branch after a PR has been merged with stable?  Is this to be the original
> PR author, or instead someone dedicated to doing this within the yt
> community (perhaps for a month at a time)?  Either way, this is potentially
> a considerable onus for someone, particularly (as you note) in cases where
> the bugfix code works differently between stable and dev branches.  We
> already have a relatively moderate learning curve associated with new users
> trying to contribute code (learning BB, merging to the correct branch,
> correcting code after comments, etc.), and my concern is that this
> additional task may be just one more hurdle that keeps new devs away from
> contributing.  But perhaps I'm wrong.  At least for veteran developers, I
> don't think the additional work will be that much of a challenge.
>

I mention in the YTEP that backporting fixes from dev to stable will be the
responsibility of whoever merged the PR in.

I think you're more focused on forward porting the fixes that go to
stable.  If the fix is sufficiently different between stable and dev, I
agree this does add a bit more of an onus on whoever is managing the
merging between stable and dev.  That said, I think it will be pretty rare
to see fixes that aren't easy to port from stable to dev, unless we decide
to make another yt-3.0 style major code change. If the fix is sufficiently
complicated, we can always open an issue about the bug in dev, while
merging in the fix to stable so our users get bugfixes quickly.

I agree that introducing technical debt based on process complexity is
bad.  However, I think not making sure bugfixes make their way to our users
is worse.  We should at all times be maximally empathetic with our users,
even if that makes our lives as developers more difficult.

Perhaps this could introduce a "maintainer" role, whose job would be to
ensure bugfixes go from stable to dev?

> So in general, I am for the suggested change, but I think we need to think
> about how best to address some of these concerns moving forward.
>
> On Wed, Jan 14, 2015 at 3:02 AM, Suoqing JI <suoqing at physics.ucsb.edu>
> wrote:
>
>> Hi,
>>
>> I agree to the suggestion that the bugfix should also go into the stable
>> branch.
>>
>> as soon as a bugfix pull request to stable goes in, there should be an
>> accompanying merge from the stable branch into the yt branch to ensure that
>> both branches get bug fixes.
>>
>>
>> This is one possible way of doing it, so we can avoid the potential
>> “mixing” of the new features in yt branch into the stable branch:
>> http://stackoverflow.com/questions/7165989/mercurial-apply-a-bugfix-change-from-stable-named-branch-to-dev-branch
>>
>>
>> Best wishes,
>>
>> --
>> Suoqing JI
>> Ph.D Student
>> Department of Physics
>> University of California, Santa Barbara
>> CA 93106, USA
>>
>> On Jan 13, 2015, at 3:44 PM, Nathan Goldbaum <nathan12343 at gmail.com>
>> wrote:
>>
>> Hi all,
>>
>> Now that yt 3.1 is making its way out the door, I'd like to come back to
>> a discussion we had last year about bugfixes.
>>
>> I've made a pull request to the YTEP repository that summarized the
>> change I'm proposing:
>>
>>
>> https://bitbucket.org/yt_analysis/ytep/pull-request/48/modify-ytep-1776-to-require-that-bugfixes/diff
>>
>> Basically, I think bugfixes need to go to the stable branch rather than
>> the yt branch.  Currently, all new changes go to the yt branch.  While this
>> does simplify our development practices, this makes it difficult for us to
>> release new versions that only include fixes for bugs.  Instead, even minor
>> version releases that are cut from the yt branch include new features and
>> API breakages.
>>
>> I think this approach violates the principle of least surprise for users
>> who have download a bugfix release.
>>
>> The solution, I think, is to ensure bugfixes are only applied to the
>> stable branch.  This will ensure that we can straightforwardly do bugfix
>> releases that inlude only bugfixes and that new features and API changes
>> are isolated to the more "experimental" yt branch.
>>
>> This does come with some possible down sides.  In particular, there will
>> likely be some confusion as we switch our development practices.  In
>> addition, new contributors may find it difficult to split pull requests
>> into new features that should go to the yt branch and bugfixes that should
>> go to the stable branch.  It also adds a new maintenance burden: as soon as
>> a bugfix pull request to stable goes in, there should be an accompanying
>> merge from the stable branch into the yt branch to ensure that both
>> branches get bugfixes.  This gets more complicated if the bugfix looks
>> different in the yt branch and the stable branch.
>>
>> All that said, I think these new maintenance burdens can be overcome with
>> a bit of vigilance and maybe some new tooling.
>>
>> I've probably said enough about this.  What do you all think?  Comments
>> and concerns are very welcome.
>>
>> Best,
>>
>> Nathan Goldbaum
>> _______________________________________________
>> 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
>>
>>
>
>
> --
> Cameron Hummels
> Postdoctoral Researcher
> Steward Observatory
> University of Arizona
> http://chummels.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/20150116/56541906/attachment.html>