[yt-users] Fwd: Changes to yt source code hosting

[Matthew Turk]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20170307/737e448c/attachment.htm>