On Sat, Jan 17, 2015 at 8:22 AM, Sam Skillman <samskillman@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.

Unfortunately this won't work for technical reasons.  We can choose to change the destination branch for the PR, but we can't choose which branch the commits are originally on.  As soon as we start making pull requests from the stable branch to the yt branch, the stable branch will grow additional non-topological heads (i.e. the last commit on the stable branch before it is merged into the yt branch will be listed in "hg heads" on the stable branch).  Since the PR was moved from the stable to the yt branch, that means that a head on the stable branch will have new features.

These extra heads can be manually squashed with a no-op merge, but that will introduce further disruption when we eventually merge the yt branch into the stable branch on release.

If anything, we will need to be extra careful to make sure pull request commits happen on the correct branch.  So, if a PR comes in originally on the stable branch, and we decide that it should really be on the yt branch, someone will need to rebase the commits onto the correct branch.

I tend to think this will work out best if have a person whose job is to land pull requests correctly.  This person should have decent knowledge of mercurial, since they may need to manually graft, rebase, or cherry-pick changes from one branch to the other to keep our branch structure clean.

I don't think this will be a terribly big responsibility, particularly if we are ok with ~weekly (or even less often) merges from the stable branch into the yt branch. That said, this person would also need to keep on top of the PR queue to ensure that pull requests aren't mistakenly merged into the correct branch.

FWIW, if I weren't worrying about graduating and searching for jobs I'd be happy to volunteer for this position...

-Nathan
 

Cheers,
Sam

On Sat Jan 17 2015 at 8:06:39 AM Ben Thompson <bthompson2090@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@gmail.com> wrote:
+1

On Sat, Jan 17, 2015 at 5:07 AM, Britton Smith <brittonsmith@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@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@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@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@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:


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@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org


_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org



_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org



_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org



_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org




--
Cameron Hummels
Postdoctoral Researcher
Steward Observatory
University of Arizona

_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org