Giters

elm-community / guidelines

guidelines for *-extra contributors

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Tranfer of -extra repos from CircuitHub

mgold opened this issue · comments

commented

Following this mailing list thread, I sent @rehno-lindeque sent me the following email.

Hi Max, so I see three options:

  • elm-discuss forks from CircuitHub.
  • elm-discuss clones from CircuitHub and re-upload to GitHub.
  • CircuitHub transfers the repos to elm-discuss and then immediately forks them in order to correct the "upstream" relationship on GitHub without breaking elm-package.

I think the third option might be the best since existing PRs / issues are transferred and people will naturally move upstream to log new issues / submit PRs. You could then delete all of the existing version tags, copy master branch to a elm-0.16 branch and start fresh with a 1.0.0 commit to master. How does this sound?

This is the list of people currently on the maintainers list. Feel free to invite anyone you'd like. I reckoned we could just yank their permissions if anyone caused problems, but thus far everyone has behaved outstandingly (some are commercial users). (It looks as though we had fewer maintainers than I was expecting though)

And then a list of people.

How does everyone feel about how to manage this?

commented

Third option seems best to me. I'll delete the fork of json-extra so it doesn't get in the way of this. It wasn't published and there was no new activity anyway.

commented

Migrate repos to github, but don't publish til 0.17

commented

Option 3 sounds good. Perhaps we should try it with one of the least-used packages first to make sure that elm-package works fine afterwards. And will elm-package handle the missing repo gracefully enough between when the repo is transferred and when circuithub forks it back again?

commented

It looks like github sets up a redirect at least for a repo's webpage when its ownership is transferred. For example, opening https://github.com/lukewestby/builtwithelm will take you to the repo in this org.

commented

Okay, so that's

  • Test with a less popular repo first
  • Transfer ownership to this org, which sets up a redirect so nothing breaks
  • Keep the tags so those don't break
  • Update and release 1.0.0 when 0.17 drops
commented

It won't even break elm-package from downloading things thanks to the redirect also working for zips, so that's good

commented

Test with a less popular repo first

Ok, great! Sorry, I missed this issue. elm-function-extra looks like the least recently updated one. I'll give that one a go...

commented

I've hit a small snag:
screen shot 2016-03-08 at 11 27 22 am

commented

@rehno-lindeque I've just invited you and given you owner permissions, which means I'm obligated to say something along the lines of don't abuse it and keep your account secure.

commented

Ok, followed those steps for elm-function-extra. I also did a quick bit of cleanup - for posterity:

for f in ./elm-*-extra ; do sed --in-place "s/201[45] CircuitHub/2016 CircuitHub Inc.\, Elm Community members/" $f/LICENSE ;done
for f in ./elm-*-extra ; do (sed --in-place "s/\"version\":\s*\".*\"/\"version\": \"1.0.0\"/" $f/elm-package.json); done
for f in ./elm-*-extra ; do (sed --in-place "s/\/circuithub\//\/elm-community\//" $f/elm-package.json > $f/elm-package.json); done
for f in ./elm-*-extra ; do (sed --in-place 's/^---$//;/^\[\!\[CircuitHub team\].*/,$d' -- $f/README.md); cat $f/README.md; done
commented

To test:

  • install under old name
  • install under new name (should fail)
  • publish under new name (should fail)
  • check out each tag and publish at that tag (should pass, start at 1.0.0)
  • install under new name
commented

After that, migration can be considered successful

commented

So, I did end up forking the package to CircuitHub as well, fyi. So existing packages should work.

I think all that is left for elm-community might be something in the lines of:

# Delete all tags
for t in `git tag`
do
    git push origin :$t
    git tag -d $t
done

# Publish at version 1.0.0
git tag -a 1.0.0 -m "First version"
elm package install # Check if dependencies are ok?
elm package publish
commented

Oh, I see,you republished as 1.0.0? Hmm, I think it is best to keep older versions after the migration.

commented

elm-community's version will be considered a separate package, and therefore must start at 1.0.0.

It looks like Rehno has not deleted the tags yet. I also notice that this package hasn't been updated for 0.16, which means it's unlikely to break things, but also that the audience is small or nonexistent.

The best course of action is probably to keep the tags CircuitHub's fork. Again it probably won't matter for this package but it's best not to break things. Then as Rehno suggests, delete all tags in elm-commnity's copy, verify things work, and push and publish 1.0.0.

Since this is a major release anyway, I want to skim over the API and see if there's anything that I think should be changed.

commented

elm-community's version will be considered a separate package, and therefore must start at 1.0.0

I'm pretty sure that @eeue56 is well aware of that, and that it's because of this that he suggested:

  • check out each tag and publish at that tag (should pass, start at 1.0.0)

This way, of course the package will start at 1.0.0, but nevertheless all versions will be preserved in the exact same way as they were under the previous user name.

commented

Okay, fine. I was a little confused about his other comment, right before mine, but I see that is now referring to circuit-hub's copy.

commented

So, this is what I believe is best practice:

  • When migrating a package, the old package repo does not need to exist. Github will set up the redirects. So there is no need for forking in order to maintain packages. See here for more information on redirects. It's fine if you want to fork it back to the original, but there's no need for it and will lead to confusion. If instead you don't have a fork, when the user clicks on "browse source", they will get redirected the actual version rather than the outdated fork. This helps prevents issues where people open PRs and issues against dead repos.
  • When the new package is published, it should include all previous versions that were published until that point. The reasoning here is pretty simple: multiple times in production, we have used elm-package diff to compare the API changes between multiple versions to figure out why we have bugs, or why code isn't compiling any more. If you republish a package that is in use in production as 1.0.0, then you can no longer diff things to see what has changed. Additionally, it is a standard thing where if we have to choose between multiple packages, and there is one with only 1.0.0, and another 3.0.4 (i.e well maintained) then we are more likely to go for the one with multiple releases. It gives more weight (even if artificially) to the package.
commented

The nicest solution to bullet number 2 would be able to do something like elm package diff circuit-hub/elm-function-extra 1.2.2 elm-community/elm-function-extra 1.0.0. As it stands you can only diff against one package. When elm-community publishes 1.0.0 but retains 1.2.2, which was never published under elm-community... at best your diff will be backwards, because 1.0.0 is newer than 1.2.2. At worst it won't work. (I'm not saying you're wrong; I'm saying I'm confused.)

When considering how well-maintained a package is, I would think elm-community would be recognized as good maintainers, or at least as maintainers of packages that have had several releases under another name. This doesn't help for forks/transfers that don't involve elm-community, of course.

commented

You folk are welcome to roll back over the last commit which resets the version to 1.0.0. I do want to recommend against however - I think you might be making far too much work for yourselves...

  • At one point or another CircuitHub is inevitably going to fork from elm-community in order to do our own maintenance and from there things get confusing for everyone (suddenly the package no longer points to the elm-community/ repo but back to a circuithub/ repo).
  • I feel circuithub/ namespace on http://package.elm-lang.org should refer to circuithub/ namespace on http://github.com. Anything else just leads to more questions than answers.
  • For diffs if it's a big concern you could tag/publish the current version as 1.0.0 and then the version published with Elm 0.17 would be the next bump after that.

I think the least confusing path is for people is to explicitly select the elm-community/elm-foo-extra version of a package in their elm-package.json and treat it as a brand new package. I don't mind pointing people to elm-community for PRs/issues. Very soon unmaintained circuithub/ versions will be marked deprecated on https://package.elm-lang.org making it clear that the elm-community versions are the correct packages to use.

commented

@mgold, the idea of @eeue56's suggestion is that elm-community's 1.0.0 will be an exact copy of circuithub's 1.0.0. So there will be no "backwards" as you fear.

commented

Janis: Okay, now I understand the proposal. I agree with Rehno about treating them as separate packages, or perhaps with the third bullet, publishing the current version as 1.0.0 but discarding earlier history.

commented

. I do want to recommend against however - I think you might be making far too much work for yourselves

It's important to set a good precedent here, because a bad one will lead to bad elm experiences. So the initial cost might be high (well, writing a 6 line script), but I think the returns are good.

At one point or another CircuitHub is inevitably going to fork from elm-community in order to do our own maintenance and from there things get confusing for everyone (suddenly the package no longer points to the elm-community/ repo but back to a circuithub/ repo).

This isn't a problem uneless you start to publish versions with the fork, but I get the reasoning. As long as you don't publish new versions then it will be forever locked to the last version you published with, regardless of fork or not. As long as you don't do naughty things with tags that is.

I feel circuithub/ namespace on http://package.elm-lang.org should refer to circuithub/ namespace on http://github.com. Anything else just leads to more questions than answers

This is a fair point, but I think there's going to be some level of confusion no matter what.

For diffs if it's a big concern you could tag/publish the current version as 1.0.0 and then the version published with Elm 0.17 would be the next bump after that.

it's important to be able to diff every release, not just the head

Very soon unmaintained circuithub/ versions will be marked deprecated on https://package.elm-lang.org making it clear that the elm-community versions are the correct packages to use.

This is only true right now, because of the alignment with 0.17. Again we should be using this as a chance to get it right.

commented

I'm happy to write the tooling for automating what I think is best practice. I don't want to be a blocker here, so if someone else wants to come back with a proposal based on this discussion then that's cool too.

commented

I favor re-publishing the ported repos to reestablish all the tagged versions as @eeue56 suggests.

Doing that via a script if possible sounds good.

There are some 68 tags in the 7 elm-*-extra repos. (elm-html-extra has no tags). Is there any concern about the impact on package.elm-lang.org of adding so many packages at once?

Have we agreed to not publish any version of the ported repos until Elm 0.17 is out? Perhaps we could publish a few versions of some ported repo to verify that "elm-package publish" works for those old versions, some of which don't have elm-version in elm-package.json (at the time of the tag)

commented

Hi again, I thought I'd quickly poke folks again about these three repos:

Would elm-community be willing to take these under its wing?

commented

I would say so, and we can start transferring them now, but I'd like to not publish the new versions until 0.17 is finalized, just in case something big changes between now and then. (My 2c, Noah knows more than me here.)

commented

I don't think that anything big will change as far as these libraries go. We should start porting them 👍

commented

I've transfered these over to elm-community and forked back to circuithub, same as last time. I didn't update the elm-package.json files this time to point to their new repo, but it is pretty trivial to do.