[yt-dev] Proposed change to development practices

Sun Jan 18 05:17:52 PST 2015

Sam, this is an interesting idea that I think could work.  Perhaps we still
need someone like a maintainer to keep us on a release schedule.  Maybe
this is a separate conversation, but it seems to me that the schedule
releases tend to slip because it's not clear who is in charge of them.

On Sat, Jan 17, 2015 at 4:22 PM, Sam Skillman <samskillman at gmail.com> wrote:

> 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
>>
>
> _______________________________________________
> 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/20150118/0510fe0c/attachment.htm>
-------------- next part --------------
_______________________________________________
yt-dev mailing list
yt-dev at lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org