[yt-dev] Proposed change to development practices

Thu Jan 22 00:09:22 PST 2015

Ok, this sounds good to me.

On Wed, Jan 21, 2015 at 11:05 PM, John ZuHone <jzuhone at gmail.com> wrote:

> OK, after looking over the last few emails I’m convinced.
>
> +1
>
> On Jan 21, 2015, at 5:57 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
>
>
>
> On Wed, Jan 21, 2015 at 2:05 PM, John ZuHone <jzuhone at gmail.com> wrote:
>
>> This is starting to look like something that is pretty likely to get done
>> wrong by accident often. I know I wouldn’t trust myself to do it right.
>>
>>
> I believe only one person needs to do this and Matt is volunteering to do
> it.  Most contributors will just need to mark bugfixes as such, or mention
> that something should be backported.
>
>
>> On Jan 19, 2015, at 12:25 PM, Matthew Turk <matthewturk at gmail.com> wrote:
>>
>> Hi Sam and Britton,
>>
>> Okay, I think this is what we could do, although I'm somewhat concerned
>> that if we do "merge" from yt into stable we will catch the new development
>> too.  I was in my head thinking about periodic merges from stable into yt,
>> so that bugfixes propagate that way, which I think would work for this.
>>
>> I'd also like to put out there that we do have the ability to do this on
>> our own, particularly with the hgbb extension.  In fact, we could make it
>> all a one-line command to backport based on PR number.  One could imagine
>> the maintainer seeing the bugfix, and then running a command line this:
>>
>> hg yt_backport -n 1432
>>
>> This would be an alias that performed these operations:
>>
>> hg hgbbpr -p 1432
>> hg pull -r stable https://bitbucket.org/yt_analysis/yt
>> hg rebase --collapse -s "last(pr(1432))" -d stable -m "Backporting PR
>> #1432 to stable" --keep
>> hg push -r stable https://bitbucket.org/yt_analysis/yt
>>
>> This would pull in PR 1432, turn it into a single commit, commit that
>> commit with the message onto stable, and then push the new single commit
>> back up.  It would avoid too much commit count increasing, and would also
>> be nice and easy.  The maintainer could do this, or we could even have Fido
>> do it whenever a BUGFIX PR got committed to yt.  (Or if we marked it as
>> BACKPORT in the comments or something.)
>>
>> Thoughts?
>>
>> On Sun, Jan 18, 2015 at 7:17 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
>>
>>
> _______________________________________________
> 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/20150122/ece4be9d/attachment.html>
-------------- next part --------------
_______________________________________________
yt-dev mailing list
yt-dev at lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org