<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">OK, after looking over the last few emails I’m convinced. <div class=""><br class=""></div><div class="">+1</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 21, 2015, at 5:57 PM, Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com" class="">nathan12343@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><br class="Apple-interchange-newline"><br class=""><div class="gmail_quote">On Wed, Jan 21, 2015 at 2:05 PM, John ZuHone<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:jzuhone@gmail.com" target="_blank" class="">jzuhone@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class="">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. <div class=""><div class="h5"><div class=""><br class=""></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class="h5"><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 19, 2015, at 12:25 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com" target="_blank" class="">matthewturk@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Hi Sam and Britton,<br class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">hg yt_backport -n 1432</div><div class=""><br class=""></div><div class="">This would be an alias that performed these operations:</div><div class=""><br class=""></div><div class="">hg hgbbpr -p 1432</div><div class="">hg pull -r stable<span class="Apple-converted-space"> </span><a href="https://bitbucket.org/yt_analysis/yt" target="_blank" class="">https://bitbucket.org/yt_analysis/yt</a></div><div class="">hg rebase --collapse -s "last(pr(1432))" -d stable -m "Backporting PR #1432 to stable" --keep</div><div class="">hg push -r stable<span class="Apple-converted-space"> </span><a href="https://bitbucket.org/yt_analysis/yt" target="_blank" class="">https://bitbucket.org/yt_analysis/yt</a></div><div class=""><br class=""></div><div class="">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.)</div><div class=""><br class=""></div><div class="">Thoughts?</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Jan 18, 2015 at 7:17 AM, Britton Smith<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:brittonsmith@gmail.com" target="_blank" class="">brittonsmith@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class="">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.</div><div class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Jan 17, 2015 at 4:22 PM, Sam Skillman<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:samskillman@gmail.com" target="_blank" class="">samskillman@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">Hi all, <br class=""><br class=""><div class="">I'm in broad favor of this change in development practice. However, I want to float an idea and see how people feel:</div><div class="">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.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Sam</div><div class=""><div class=""><br class=""><div class="gmail_quote">On Sat Jan 17 2015 at 8:06:39 AM Ben Thompson <<a href="mailto:bthompson2090@gmail.com" target="_blank" class="">bthompson2090@gmail.com</a>> wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><p dir="ltr" class="">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.</p><p dir="ltr" class="">Ben</p><div class="gmail_quote">On 17 Jan 2015 15:33, "Cameron Hummels" <<a href="mailto:chummels@gmail.com" target="_blank" class="">chummels@gmail.com</a>> wrote:<br type="attribution" class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class="">+1</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Jan 17, 2015 at 5:07 AM, Britton Smith<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:brittonsmith@gmail.com" target="_blank" class="">brittonsmith@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class="">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?</div><div class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Jan 17, 2015 at 2:17 AM, Matthew Turk<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:matthewturk@gmail.com" target="_blank" class="">matthewturk@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class="">Hi Britton,<div class=""><br class=""></div><div class="">I think there are a few ways to address this.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">One thing we also have fallen away from, which we had for a while, was the very rigorous and regular release schedule...</div></div><div class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jan 16, 2015 at 8:46 AM, Britton Smith<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:brittonsmith@gmail.com" target="_blank" class="">brittonsmith@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class="">Hi Nathan,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">Britton</div></font></span><div class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jan 14, 2015 at 10:02 AM, Suoqing JI<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:suoqing@physics.ucsb.edu" target="_blank" class="">suoqing@physics.ucsb.edu</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class="">Hi,<div class=""><br class=""></div><div class="">I agree to the suggestion that the bugfix should also go into the stable branch.</div><span class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="">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.</div></div></blockquote><br class=""></div></span><div class="">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: <a href="http://stackoverflow.com/questions/7165989/mercurial-apply-a-bugfix-change-from-stable-named-branch-to-dev-branch" target="_blank" class="">http://stackoverflow.com/questions/7165989/mercurial-apply-a-bugfix-change-from-stable-named-branch-to-dev-branch</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Best wishes,</div><div class=""><br class=""><div class=""><div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; word-wrap: break-word;" class=""><div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; word-wrap: break-word;" class=""><div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; word-wrap: break-word;" class=""><div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; word-wrap: break-word;" class=""><div class="">--</div><div class="">Suoqing JI</div><div class="">Ph.D Student</div><div class="">Department of Physics</div><div class="">University of California, Santa Barbara</div><div class="">CA 93106, USA</div></div></div></div></div></div><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">On Jan 13, 2015, at 3:44 PM, Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com" target="_blank" class="">nathan12343@gmail.com</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class=""><div dir="ltr" class="">Hi all,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I've made a pull request to the YTEP repository that summarized the change I'm proposing:</div><div class=""><br class=""></div><div class=""><a href="https://bitbucket.org/yt_analysis/ytep/pull-request/48/modify-ytep-1776-to-require-that-bugfixes/diff" target="_blank" class="">https://bitbucket.org/yt_analysis/ytep/pull-request/48/modify-ytep-1776-to-require-that-bugfixes/diff</a><br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I think this approach violates the principle of least surprise for users who have download a bugfix release.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">All that said, I think these new maintenance burdens can be overcome with a bit of vigilance and maybe some new tooling.</div><div class=""><br class=""></div><div class="">I've probably said enough about this. What do you all think? Comments and concerns are very welcome.</div><div class=""><br class=""></div><div class="">Best,</div><div class=""><br class=""></div><div class="">Nathan Goldbaum</div></div></div></div>_______________________________________________<br class="">yt-dev mailing list<br class=""><a href="mailto:yt-dev@lists.spacepope.org" target="_blank" class="">yt-dev@lists.spacepope.org</a><br class=""><a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank" class="">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br class=""></div></blockquote></div><br class=""></div></div><br class="">_______________________________________________<br class="">yt-dev mailing list<br class=""><a href="mailto:yt-dev@lists.spacepope.org" target="_blank" class="">yt-dev@lists.spacepope.org</a><br class=""><a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank" class="">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br class=""><br class=""></blockquote></div><br class=""></div></div></div></div><br class="">_______________________________________________<br class="">yt-dev mailing list<br class=""><a href="mailto:yt-dev@lists.spacepope.org" target="_blank" class="">yt-dev@lists.spacepope.org</a><br class=""><a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank" class="">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br class=""><br class=""></blockquote></div><br class=""></div></div></div><br class="">_______________________________________________<br class="">yt-dev mailing list<br class=""><a href="mailto:yt-dev@lists.spacepope.org" target="_blank" class="">yt-dev@lists.spacepope.org</a><br class=""><a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank" class="">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br class=""><br class=""></blockquote></div><br class=""></div></div></div><br class="">_______________________________________________<br class="">yt-dev mailing list<br class=""><a href="mailto:yt-dev@lists.spacepope.org" target="_blank" class="">yt-dev@lists.spacepope.org</a><br class=""><a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank" class="">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br class=""><br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>--<span class="Apple-converted-space"> </span><br class=""><div class="">Cameron Hummels<div class="">Postdoctoral Researcher</div><div class="">Steward Observatory</div><div class="">University of Arizona</div><div class=""><a href="http://chummels.org/" target="_blank" class="">http://chummels.org</a></div></div></div><br class="">_______________________________________________<br class="">yt-dev mailing list<br class=""><a href="mailto:yt-dev@lists.spacepope.org" target="_blank" class="">yt-dev@lists.spacepope.org</a><br class=""><a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank" class="">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br class=""><br class=""></blockquote></div>______________________________<u class=""></u>_________________<br class="">yt-dev mailing list<br class=""><a href="mailto:yt-dev@lists.spacepope.org" target="_blank" class="">yt-dev@lists.spacepope.org</a><br class=""><a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank" class="">http://lists.spacepope.org/<u class=""></u>listinfo.cgi/yt-dev-spacepope.<u class=""></u>org</a><br class=""></blockquote></div></div></div><br class="">_______________________________________________<br class="">yt-dev mailing list<br class=""><a href="mailto:yt-dev@lists.spacepope.org" target="_blank" class="">yt-dev@lists.spacepope.org</a><br class=""><a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank" class="">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br class=""><br class=""></blockquote></div><br class=""></div></div></div><br class="">_______________________________________________<br class="">yt-dev mailing list<br class=""><a href="mailto:yt-dev@lists.spacepope.org" target="_blank" class="">yt-dev@lists.spacepope.org</a><br class=""><a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank" class="">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br class=""><br class=""></blockquote></div><br class=""></div>_______________________________________________<br class="">yt-dev mailing list<br class=""><a href="mailto:yt-dev@lists.spacepope.org" target="_blank" class="">yt-dev@lists.spacepope.org</a><br class=""><a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank" class="">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br class=""></div></blockquote></div><br class=""></div></div></div></div><br class="">_______________________________________________<br class="">yt-dev mailing list<br class=""><a href="mailto:yt-dev@lists.spacepope.org" class="">yt-dev@lists.spacepope.org</a><br class=""><a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank" class="">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br class=""><br class=""></blockquote></div><br class=""></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">yt-dev mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:yt-dev@lists.spacepope.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">yt-dev@lists.spacepope.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a></div></blockquote></div><br class=""></div></body></html>