<div dir="ltr"><div><div class="gmail_quote">Hi everyone,<br>
<br>
<br>
The yt steering committee (Hilary Egan, Nathan Goldbaum, Cameron<br>
Hummels, Kacper Kowalik, Sam Skillman, Britton Smith, Matthew Turk and<br>
John ZuHone) proposes that we move the hosting infrastructure for yt<br>
from BitBucket to GitHub, and as a side effect, migrate the primary<br>
version control system from mercurial to git.<br>
<br>
This decision wasn’t taken lightly, and it’s with more than a little<br>
sadness that I’m writing this email.  Beneath the “next steps” stuff,<br>
I’ve detailed some of the rationale behind this, and outlined some of<br>
our thinking.  First, however, I’ll outline the next steps and what<br>
this means for the (overlapping, non-disjoint) developer and user<br>
communities.<br>
<br>
What’s Next:<br>
<br>
* This email is to serve as a solicitation of comments; if you wish to<br>
just say, “+1” or “me too” or anything along those lines, please feel<br>
free to not send that email.  If you have reservations, concerns to<br>
raise, suggestions for the conversion process itself, or opinions<br>
about the outline, please do contribute.<br>
* The conversion process and plans for migrating code, issues, etc<br>
will be detailed in a YTEP.  What will almost certainly happen is that<br>
for a period of time, we’ll have mirrors on both GH and BB, but at any<br>
given time only one will be open for pull requests and code review.<br>
(i.e., there’ll be a switch-flipping at some point to move, but we’ll<br>
ease into it.)  We anticipate this will be on the scale of months, not<br>
hours or days.<br>
* We decide on a timeline for when we turn off pull requests on the<br>
old repository and turn them on on a new one.<br>
* We’ll be figuring out how to move infrastructure (fido) to GitHub as<br>
part of the YTEP.<br>
<br>
What this means for you as someone who contributes, or runs off the mainline:<br>
<br>
* At some point in the future, you will need to issue pull requests to<br>
a repository on GitHub.<br>
* Code reviews will happen on GitHub, and our process may change slightly.<br>
* The yt repository on BitBucket will, for the foreseeable future, be<br>
available, and we will mirror changes from GH for at least the<br>
mid-term future, potentially much longer.  All previous code reviews<br>
will be backed up, but for reference will continue to be available on<br>
BitBucket.<br>
* If you auto-update and want to push changes back up, you’ll be<br>
grabbing from another place; this likely means re-cloning.<br>
<br>
What this means for someone who runs yt:<br>
<br>
* If you are using nightly or stable builds from pip, anaconda or<br>
conda-forge, you should have no interruption whatsoever.<br>
* If you’re running from the source repository, you may or may not<br>
need to re-clone (with git), depending on the timescale of the mirror<br>
continuing to run.<br>
<br>
Big Things To Discuss:<br>
<br>
* When we do flip the BB->GH switch is not clear; there are arguments<br>
to be made for both “right away” and “in the summer.”  There are some<br>
big in-flight PRs that maybe should go in before we move.<br>
* We’ll need to decide about things like squashing commits, rebasing,<br>
etc.  That can happen later.<br>
<br>
I suppose that’s it.  Thanks for reading.  Unless we hear big<br>
objections, we’ll draft a YTEP in the next week or two with some more<br>
information, and then use that as an opportunity to finalize a<br>
timeline.<br>
<br>
-Matt, on behalf of the yt steering committee<br>
<br>
<br>
Appendix: Rationale<br>
<br>
I’ll start this out with a personal comment.  Discussions about this<br>
have happened from time to time.  I’d always, always pushed back.  (I<br>
wasn’t the only one, but I was usually pretty vocal.)  This time, I<br>
was the one who brought it up.<br>
<br>
My reasoning, which is certainly not original, is that there are two<br>
main reasons we should move.  I want to emphasize neither of these is<br>
related to hg; in fact, I’m incredibly sad about hg, and only a little<br>
sad about leaving bitbucket.  I’ll probably still use hg-git to manage<br>
git via hg, and I’ll still happily talk about how amazing hg is.<br>
<br>
Reason 1: It’s an inclusion issue.  There is evidence that any<br>
additional barriers to entry dramatically reduce participation in the<br>
development of open source projects, and there is evidence that these<br>
barriers disproportionately affect underrepresented and minoritized<br>
groups.  We have seen a decline in new contributions to yt.<br>
Furthermore, the regular contributors to yt do not match the diversity<br>
of the astronomical community (which, despite our efforts to be<br>
interdisciplinary, is still our original home.)  Asking people to jump<br>
through additional hurdles helps neither of these problems.<br>
<br>
Reason 2: There is an ecosystem around GitHub that we are not able to<br>
participate in.  Things like <a href="http://depsy.org" rel="noreferrer" target="_blank">depsy.org</a>, the other astronomy or<br>
physical sciences projects, and the like.  The advantage of a<br>
monoculture (lowering barriers to entry) is also the disadvantage of a<br>
monoculture in terms of an ecosystem.  By moving to GitHub, we will<br>
gain access to this ecosystem.<br>
<br>
I could go on at length about these two reasons, but I’ll just leave<br>
it there.  For me, the first reason is the vastly more important one,<br>
but both are valid.<br>
<br>
This decision wasn’t taken lightly, and a number of issues were raised<br>
-- not the least of which is reducing disruption to people that are<br>
either clearly “users” or “developers” as well as the community of<br>
dev-users.  One issue that has been brought up is that every “disrupt<br>
people’s workflow” token we spend has a real cost, and we should not<br>
use them lightly.  What we arrived at, which was a consensus if not a<br>
consensus that left everyone entirely happy, was that this case is<br>
worth one of those tokens.<br>
<br>
-Matt, on behalf of himself<br>
</div><br></div></div>