[yt-dev] Proposed change to development practices

Cameron Hummels chummels at gmail.com
Sat Jan 17 07:25:35 PST 2015


+1

On Sat, Jan 17, 2015 at 5:07 AM, Britton Smith <brittonsmith at gmail.com>
wrote:

> I want to reaffirm my support for having what Nathan has now referred to
> as a "maintainer."  I don't see a way of upholding procedural complexity
> without the intervention of an officially designated human being.  Who is
> for/against this?
>
> On Sat, Jan 17, 2015 at 2:17 AM, Matthew Turk <matthewturk at gmail.com>
> wrote:
>
>> Hi Britton,
>>
>> I think there are a few ways to address this.
>>
>> One would be to encourage developers to do all their day-to-day work on
>> stable.  Another would be for all bugfix PRs to get automatically grafted
>> (and squashed) onto the stable branch or the yt branch.
>>
>> One thing we also have fallen away from, which we had for a while, was
>> the very rigorous and regular release schedule...
>>
>> On Fri, Jan 16, 2015 at 8:46 AM, Britton Smith <brittonsmith at gmail.com>
>> wrote:
>>
>>> Hi Nathan,
>>>
>>> This is a good discussion to be having and I definitely agree that
>>> bugfixes need to be making their way to the stable branch in real time.
>>> The added complication in procedure does worry me, specifically for someone
>>> whose first ever PR is to fix a bug they find, but I imagine even
>>> experienced developers are going to have trouble remembering.
>>>
>>> I think this might go a lot more smoothly if we had someone officially
>>> designated for this duty, their job being to immediately push bugfixes
>>> to/from stable.  If we had that, then we could continue to have all PRs go
>>> into the development branch.  What do people think about this?  If it were
>>> a rotating position, changing hands after releases, it might work.
>>>
>>> Britton
>>>
>>> On Wed, Jan 14, 2015 at 10: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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20150117/6d9ff881/attachment.htm>


More information about the yt-dev mailing list