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