[yt-dev] Proposed change to development practices

Sat Jan 17 08:22:26 PST 2015

Hi all,

I'm in broad favor of this change in development practice.  However, I want
to float an idea and see how people feel:
At any time a pull request can be updated to change the branch to which it
is being applied, without re-issuing the pull request.  Therefore, perhaps
we could just suggest that all pull requests start out as a pull request on
the stable branch, and if through the pr review process it is deemed more
than a bugfix, it can be switched to the yt branch.  I think that this
mode, combined with bringing back a hard release schedule, could work quite
well.  Anyways, just wanted to throw that out there.

Cheers,
Sam

On Sat Jan 17 2015 at 8:06:39 AM Ben Thompson <bthompson2090 at gmail.com>
wrote:

> Yeah, I agree with the idea that we should have one branch where we push
> the updates. And the obvious bug fixes should be pushed into the stable
> repo (monitored by one person a month). Then put any of the new features
> into each new release. This means if people want a stable version that
> works, then they can have it (potentially means less updates for them too)
> Or if they want new features, then they can have that too.
>
> Ben
> On 17 Jan 2015 15:33, "Cameron Hummels" <chummels at gmail.com> wrote:
>
>> +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
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20150117/227098cc/attachment.html>