Re: [yt-dev] Proposal: Move main repo to github May 1
by Matthew Turk
Hi all,
Let's move ahead with this. Starting tomorrow, the GitHub repo will be
fiducial. I can send a note to yt-users.
Matt
On Apr 26, 2017 5:28 PM, "John ZuHone" <jzuhone(a)gmail.com> wrote:
+1 from me
Sent from my iPhone
On Apr 26, 2017, at 7:18 PM, Britton Smith <brittonsmith(a)gmail.com> wrote:
Hi Nathan,
+1 from me as well. I was originally in favor of this buffer period when
it seemed like there would be more work to do to get things ready, but it
seems like everything is all set.
Britton
On Wed, Apr 26, 2017 at 9:26 AM, Matthew Turk <matthewturk(a)gmail.com> wrote:
> Hi,
>
> I am strongly +1 on pulling the trigger switch on May 1. I think we'll
> gain very little from waiting, and I think we're ready.
>
> On Wed, Apr 26, 2017 at 12:20 PM, Nathan Goldbaum <nathan12343(a)gmail.com>
> wrote:
>
>> Hi all,
>>
>> I'd like to propose that we agree to "flip the switch" on switching the
>> main repository to github on May 1. That means that from May 1 we will no
>> longer accept pull requests on bitbucket and we will switch to mirroring
>> from github to bitbucket.
>>
>> When Matt originally proposed his YTEP, he suggested that we have a
>> "soft" transition where we don't accept new pull requests on bitbucket and
>> also don't accept pull requests on github. This would allow us to process
>> the currently open pull requests and give people some time to move their
>> pull requests over.
>>
>> I don't think we need to shut down all new development for two weeks.
>> Instead, I think we just need to merge in the pull requests that are
>> mergeable and open on bitbucket and then tell people to port any
>> unmergeable pull requests over to github. Matt putt together some
>> instructions on how to export pull requests here:
>> https://github.com/yt-project/bb-migration/issues/7#is
>> suecomment-296304236
>>
>> I just looked over the list of open pull requests on bitbucket and I
>> think the following pull requests can be merged:
>>
>> https://bitbucket.org/yt_analysis/yt/pull-requests/2534
>> https://bitbucket.org/yt_analysis/yt/pull-requests/2537
>> https://bitbucket.org/yt_analysis/yt/pull-requests/2539
>> https://bitbucket.org/yt_analysis/yt/pull-requests/2544
>> https://bitbucket.org/yt_analysis/yt/pull-requests/2560
>> https://bitbucket.org/yt_analysis/yt/pull-requests/2575
>> https://bitbucket.org/yt_analysis/yt/pull-requests/2580
>> https://bitbucket.org/yt_analysis/yt/pull-requests/2584
>> https://bitbucket.org/yt_analysis/yt/pull-requests/2585
>> https://bitbucket.org/yt_analysis/yt/pull-requests/2587
>> https://bitbucket.org/yt_analysis/yt/pull-requests/2589
>> https://bitbucket.org/yt_analysis/yt/pull-requests/2590
>>
>> If we can get some eyes on these pull requests in particular that would
>> be helpful. I think most or all of them can be merged in as-is, but we need
>> more code reviewers to make sure we can actually do that.
>>
>> Does anyone have objections to pulling the trigger on the switch to
>> github May 1?
>>
>> -Nathan
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev(a)lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev(a)lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
_______________________________________________
yt-dev mailing list
yt-dev(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________
yt-dev mailing list
yt-dev(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
1 year, 7 months
Starting conversation about Py2 deprecation
by Matthew Turk
Hi folks,
On the call yesterday, the topic of dropping support for Py2 came up. This
site provides some context:
http://www.python3statement.org/
At present, we're planning to have a 3.4 release sometime in the early
summer, and then aiming for a yt 4.0 sometime about six months later. yt
4.0 will have the demeshening.
A proposal was floated to have yt 4.0 be the last release that explicitly
supports python 2, and then to "softly" drop support for python 2 during
the cycle for yt 4.1, which would be about six months later, we
anticipate. This would mean not testing on py2 anymore and potentially
removing some of the shims and six calls to dual-support.
Some more discussion is in the meeting notes:
https://github.com/yt-project/meeting-notes/blob/master/notes-20170419.md
I don't know if this is something we should actively discuss yet, but I
wanted to put it out there. I personally support this proposal.
-Matt
1 year, 7 months
Exporting a pull request from BitBucket to GitHub
by Matthew Turk
Hi folks,
Here is the process I just used for exporting a pull request to GitHub. It
went incredibly smoothly. I will put this in a migration document as well.
Step 0: Make sure you have hg-git installed (it is pip installable) and
enabled in your ~/.hgrc . Enabling it looks like this:
[extensions]
hggit=
Now, here are the steps:
1. Fork http://github.com/yt-project/yt
2. In your yt source repository, update to the latest changeset of your
pull request.
3. If it does not have a bookmark, create one with "hg bookmark". It can
be something like "hg bookmark whatever_i_want_to_call_it"
4. Edit your .hg/hgrc in your yt repository. Under [paths] add a github
one. For me, it looks like this:
[paths]
default = ssh://hg@bitbucket.org/MatthewTurk/yt
ytanalysis = ssh://hg@bitbucket.org/yt_analysis/yt
gh = git@github.com:MatthewTurk/yt
ghyt = git@github.com:yt-project/yt
You will need to modify `gh` here.
5. Now, check what you're going to export. "hg outgoing -r
whatever_i_want_to_call_it gh" will show you. Make sure that this matches
what you anticipate.
6. If it all looks good, push it *with the bookmark*. "hg push -B
whatever_i_want_to_call_it gh" will do this.
7. Reopen the pull request on GitHub, and decline your pull request on
BitBucket.
Here is the one I just did: https://github.com/yt-project/yt/pull/1346
This should make things very smooth to transition. Since we're not yet
*accepting* things on GitHub, I would encourage folks to start moving their
long-term PRs. (does that sound right, Nathan and Kacper?)
-Matt
1 year, 7 months
Notes from meeting 3 and 4?
by Matthew Turk
Hi folks, does anyone have the notes from yt team meetings 3 and 4? I have
the agenda for meeting 4, but no notes. Maybe none were taken.
1 year, 7 months
Final github repo
by Nathan Goldbaum
Hi all,
I think the github mirror we set up for testing purposes has been more or
less a success:
https://github.com/yt-project/yt-test
The mirroring seems to work well: the github repository is staying in sync
with the bitbucket repo every time we merge pull requests on bitbucket. To
make further work on transitioning to github easier, I'd like to settle on
what the final converted repo should like.
For the purposes of discussion, I'd like to propose simply renaming the
yt-project/yt-test repo to be yt-project/yt and agreeing that the current
conversion is satisfactory. This means we'll agree not to use an alternate
conversion technique that will change git commit hashes.
Our mirror bot uses hg-git, and the converted repo hg-git produces isn't
necessarily perfect. In particular, two issues have come up:
* Since git is more selective than mercurial about e-mail and username
formatting, there are a number of commits associated with dummy e-mail
addresses like none@none
* Since we do most of our development on a branch named "yt" (not "default"
as is typical of mercurial repos) almost every commit in our history has a
comment in the git commit message recording that it hapenned on the "yt" or
"stable" branch. This makes it possible to round-trip from hg to git and
back to hg, but it's also some extra noise in every single commit message.
We could in principle ameliorate these issues by using something besides
hg-git to do the conversion or by modifying hg-git to avoid these issues.
The former options will lose the nice property of being able to round-trip
and for others to independently export work from their forks. The latter
option will require us to modify hg-git and waiting for upstream hg-git to
review our changes, which might take a while, or telling everyone to use a
hacked version of hg-git.
Personally, I don't think either of those options are worth the hassle for
what to me are minor annoyances. I think I've also ameliorated the
username/e-mail ambiguity in the converted history by adding a .mailmap
file to the repo:
https://bitbucket.org/yt_analysis/yt/pull-requests/2582
In addition, the mirroring process we have now seems to work well, so just
renaming the yt-test repo and calling the conversion final avoids a bunch
more work which will block further progress on the conversion.
What do you all think? It would be great to get people's +/-1 on renaming
yt-test to yt on github.com/yt-project.
Once we have a final repo name we will be able to start porting tooling
like the website generator without worrying about the name or content of
the final repo changing.
-Nathan
1 year, 7 months
Volunteers for helping with migration
by Matthew Turk
Hi folks,
We're making good progress on the migration to GitHub.
I'd like to put out a call to ask for help with a few things. The list of
outstanding issues is here:
https://github.com/yt-project/bb-migration/issues
The two things I think we need the *most* help with:
* Updating the documentation in the yt repository to change it to describe
how to fork, commit, etc, on GitHub rather than BitBucket.
* Update yt update to pull from GitHub rather than BitBucket.
If anyone can help out and try to knock some of these out, we should be on
schedule for a quick transition.
-Matt
1 year, 7 months
