[yt-dev] Proposed change to development practices

Wed Jan 21 14:15:49 PST 2015

On Mon, Jan 19, 2015 at 4:48 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> I think this is a good idea.
>
> What about my suggestion to have fido automatedly backport (or at least,
> attempt, and issue PRs) if a comment just saying "backport" is left in the
> PR?  Or, alternately, using the relatively simple set of commands I
> outlined, which could even be put into a single alias?
>
> I do not think we should add to many barriers to entry; furthermore, I
> don't like the idea of micromanaging contributions ("Please recommit this
> to stable" or "Please commit this to yt".)  I'd be fine taking on the duty
> -- and committing as something like "Backport Bot" so I don't get the
> "credit" for the commits -- of backporting PRs, if we can identify the PRs
> that need to be backported somehow.  Frankly, anything labeled as BUGFIX
> committed to the yt branch seems to me to fit the bill.
>

I think that will work and has the benefit that it avoids changes in our
development practices from the point of view of most contributors.  PRs
should still go to the "yt" branch, but we commit to backporting bugfixes
to stable as part of our PR merge process.

If there's support from others that this is the way to go, I will go ahead
and update my YTEP-1776 PR.

> -Matt
>
> On Sun, Jan 18, 2015 at 9:37 PM, Sam Skillman <samskillman at gmail.com>
> wrote:
>
>> I think this would also mean that when a PR gets switched from stable to
>> yt it would often bring all the bugfixes up with it to dev, which seems
>> like a nice added bonus and would reduce the chore of applying patches back
>> and forth.  A rotating maintainer sounds like a good idea regardless. Based
>> on my time as the Enzo PR czar and the pace of yt development, I might
>> suggest something more like a 2-3 month rotating appointment. 6 months
>> might be a bit too disruptive. Just a thought.
>>
>> Sam
>>
>> On Sun Jan 18 2015 at 11:30:28 AM Britton Smith <brittonsmith at gmail.com>
>> wrote:
>>
>>> 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
>>>>
>>>>
>>> _______________________________________________
>>> 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/20150121/673bc8c0/attachment.htm>
-------------- next part --------------
_______________________________________________
yt-dev mailing list
yt-dev at lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org