Proposed change to development practices
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-r... 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
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-f... http://stackoverflow.com/questions/7165989/mercurial-apply-a-bugfix-change-f... 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
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-r... https://bitbucket.org/yt_analysis/ytep/pull-request/48/modify-ytep-1776-to-r...
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
I like this idea, but I have a few comments.
It seems like the boundary between a bugfix and new functionality is pretty
blurred in most instances. Few are the bugfixes which are just correcting
typos or a single line of code, and oftentimes in order to fix a bug fully,
a significant amount of new code needs to go in. So I have my concerns
about how to deal with making the decision when something should go in
stable or in yt branches.
Also, who will be responsible for applying code from stable to the yt
branch after a PR has been merged with stable? Is this to be the original
PR author, or instead someone dedicated to doing this within the yt
community (perhaps for a month at a time)? Either way, this is potentially
a considerable onus for someone, particularly (as you note) in cases where
the bugfix code works differently between stable and dev branches. We
already have a relatively moderate learning curve associated with new users
trying to contribute code (learning BB, merging to the correct branch,
correcting code after comments, etc.), and my concern is that this
additional task may be just one more hurdle that keeps new devs away from
contributing. But perhaps I'm wrong. At least for veteran developers, I
don't think the additional work will be that much of a challenge.
So in general, I am for the suggested change, but I think we need to think
about how best to address some of these concerns moving forward.
On Wed, Jan 14, 2015 at 3:02 AM, Suoqing JI
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-f...
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
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-r...
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
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
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
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-f...
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
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-r...
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
On Wed, Jan 14, 2015 at 6:36 AM, Cameron Hummels
I like this idea, but I have a few comments.
It seems like the boundary between a bugfix and new functionality is pretty blurred in most instances. Few are the bugfixes which are just correcting typos or a single line of code, and oftentimes in order to fix a bug fully, a significant amount of new code needs to go in. So I have my concerns about how to deal with making the decision when something should go in stable or in yt branches.
This will be tough. I think in many cases it will be clear. When it's blurry I think it will be up to the PR reviewers.
Also, who will be responsible for applying code from stable to the yt branch after a PR has been merged with stable? Is this to be the original PR author, or instead someone dedicated to doing this within the yt community (perhaps for a month at a time)? Either way, this is potentially a considerable onus for someone, particularly (as you note) in cases where the bugfix code works differently between stable and dev branches. We already have a relatively moderate learning curve associated with new users trying to contribute code (learning BB, merging to the correct branch, correcting code after comments, etc.), and my concern is that this additional task may be just one more hurdle that keeps new devs away from contributing. But perhaps I'm wrong. At least for veteran developers, I don't think the additional work will be that much of a challenge.
I mention in the YTEP that backporting fixes from dev to stable will be the responsibility of whoever merged the PR in. I think you're more focused on forward porting the fixes that go to stable. If the fix is sufficiently different between stable and dev, I agree this does add a bit more of an onus on whoever is managing the merging between stable and dev. That said, I think it will be pretty rare to see fixes that aren't easy to port from stable to dev, unless we decide to make another yt-3.0 style major code change. If the fix is sufficiently complicated, we can always open an issue about the bug in dev, while merging in the fix to stable so our users get bugfixes quickly. I agree that introducing technical debt based on process complexity is bad. However, I think not making sure bugfixes make their way to our users is worse. We should at all times be maximally empathetic with our users, even if that makes our lives as developers more difficult. Perhaps this could introduce a "maintainer" role, whose job would be to ensure bugfixes go from stable to dev?
So in general, I am for the suggested change, but I think we need to think about how best to address some of these concerns moving forward.
On Wed, Jan 14, 2015 at 3:02 AM, Suoqing JI
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-f...
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
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-r...
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
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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
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
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-f...
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
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-r...
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
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
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
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
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-f...
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
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-r...
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
+1
On Sat, Jan 17, 2015 at 5:07 AM, Britton Smith
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
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
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
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-f...
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
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-r...
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 http://chummels.org
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"
+1
On Sat, Jan 17, 2015 at 5:07 AM, Britton Smith
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
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
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
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-f...
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
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-r...
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 http://chummels.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
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
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"
wrote: +1
On Sat, Jan 17, 2015 at 5:07 AM, Britton Smith
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
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
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
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-f...
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
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-r...
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 http://chummels.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
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
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
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"
wrote: +1
On Sat, Jan 17, 2015 at 5:07 AM, Britton Smith
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
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
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-f... > > > 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
> 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-r... > > 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 http://chummels.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
On Sat, Jan 17, 2015 at 8:22 AM, Sam Skillman
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
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"
wrote: +1
On Sat, Jan 17, 2015 at 5:07 AM, Britton Smith
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
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
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-f... > > > 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
> 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-r... > > 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 http://chummels.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
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
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
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
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"
wrote: +1
On Sat, Jan 17, 2015 at 5:07 AM, Britton Smith
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
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-f... >> >> >> 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
>> 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-r... >> >> 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 http://chummels.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
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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
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
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
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"
wrote: +1
On Sat, Jan 17, 2015 at 5:07 AM, Britton Smith
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
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-f... >> >> >> 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
>> 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-r... >> >> 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 http://chummels.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
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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.
-Matt
On Sun, Jan 18, 2015 at 9:37 PM, Sam Skillman
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
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
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
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"
wrote: +1
On Sat, Jan 17, 2015 at 5:07 AM, Britton Smith
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
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-f... >>> >>> >>> 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: >>> >>> >>> https://bitbucket.org/yt_analysis/ytep/pull-request/48/modify-ytep-1776-to-r... >>> >>> 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 http://chummels.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
_______________________________________________ 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
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.
On Jan 19, 2015, at 12:25 PM, Matthew Turk
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 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 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
mailto:brittonsmith@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
mailto: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.
Cheers, Sam
On Sat Jan 17 2015 at 8:06:39 AM Ben Thompson
mailto: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"
mailto:chummels@gmail.com> wrote: +1 On Sat, Jan 17, 2015 at 5:07 AM, Britton Smith
mailto: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
mailto: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
mailto: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
mailto: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-f... http://stackoverflow.com/questions/7165989/mercurial-apply-a-bugfix-change-f...
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
mailto: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:
https://bitbucket.org/yt_analysis/ytep/pull-request/48/modify-ytep-1776-to-r... https://bitbucket.org/yt_analysis/ytep/pull-request/48/modify-ytep-1776-to-r...
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 mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org http://chummels.org/ _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-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
On Mon, Jan 19, 2015 at 4:48 PM, Matthew Turk
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
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
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
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
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"
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
> 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-f... >>>> >>>> >>>> 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: >>>> >>>> >>>> https://bitbucket.org/yt_analysis/ytep/pull-request/48/modify-ytep-1776-to-r... >>>> >>>> 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 http://chummels.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
_______________________________________________ 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
I like the automated fido "backport" functionality on PRs that have
[BACKPORT] or [BUGFIX] in them. That would definitely lower the barrier
and keep both stable and yt in sync in terms of stability.
On Mon, Jan 19, 2015 at 5:48 PM, Matthew Turk
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.
-Matt
On Sun, Jan 18, 2015 at 9:37 PM, Sam Skillman
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
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
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
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"
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
> 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-f... >>>> >>>> >>>> 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: >>>> >>>> >>>> https://bitbucket.org/yt_analysis/ytep/pull-request/48/modify-ytep-1776-to-r... >>>> >>>> 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 http://chummels.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
_______________________________________________ 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 http://chummels.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Wed, Jan 21, 2015 at 2:05 PM, John ZuHone
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
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
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
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
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"
wrote: +1
On Sat, Jan 17, 2015 at 5:07 AM, Britton Smith
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
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-f... >>> >>> >>> 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: >>> >>> >>> https://bitbucket.org/yt_analysis/ytep/pull-request/48/modify-ytep-1776-to-r... >>> >>> 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 http://chummels.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
_______________________________________________ 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
OK, after looking over the last few emails I’m convinced. +1
On Jan 21, 2015, at 5:57 PM, Nathan Goldbaum
wrote: On Wed, Jan 21, 2015 at 2:05 PM, John ZuHone
mailto:jzuhone@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
mailto:matthewturk@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 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 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
mailto:brittonsmith@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
mailto: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.
Cheers, Sam
On Sat Jan 17 2015 at 8:06:39 AM Ben Thompson
mailto: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"
mailto:chummels@gmail.com> wrote: +1 On Sat, Jan 17, 2015 at 5:07 AM, Britton Smith
mailto: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
mailto: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
mailto: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
mailto: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-f... http://stackoverflow.com/questions/7165989/mercurial-apply-a-bugfix-change-f...
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
mailto: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:
https://bitbucket.org/yt_analysis/ytep/pull-request/48/modify-ytep-1776-to-r... https://bitbucket.org/yt_analysis/ytep/pull-request/48/modify-ytep-1776-to-r...
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 mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org http://chummels.org/ _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-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
Ok, this sounds good to me.
On Wed, Jan 21, 2015 at 11:05 PM, John ZuHone
OK, after looking over the last few emails I’m convinced.
+1
On Jan 21, 2015, at 5:57 PM, Nathan Goldbaum
wrote: On Wed, Jan 21, 2015 at 2:05 PM, John ZuHone
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
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
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
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
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"
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
> 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-f... >>>> >>>> >>>> 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: >>>> >>>> >>>> https://bitbucket.org/yt_analysis/ytep/pull-request/48/modify-ytep-1776-to-r... >>>> >>>> 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 http://chummels.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
_______________________________________________ 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
participants (8)
-
Ben Thompson
-
Britton Smith
-
Cameron Hummels
-
John ZuHone
-
Matthew Turk
-
Nathan Goldbaum
-
Sam Skillman
-
Suoqing JI