Cidram: transfer to organization

[DanielRuf]

https://help.github.com/articles/about-repository-transfers/
https://github.com/composer/packagist/issues/47

• [x] fork repo to the org and disable PRs and issues
• [x] generate new GitHub pages
• [x] change GitHub paths in composer.json and other files
• [x] update links where needed
• [x] submit the new package to packagist / composer
• [x] update hooks and services if any are set (the original repo should get the settings of the new one)
• [x] delete org repo, transfer original repo to org

Currently collecting. Add any additional steps which you think are needed. I would suggest starting transition and first preparation in the next 3 months (Juni - Aug) and the final step with the transfer after this.

Will try to find and onboard some more developers (and get more licenses from IntelliJ) and would probably donate some test instance (can run Git on my server and write some script for testing purposes).

Any feedback is very welcome.

[Maikuolan]

+1.

Transferring to the organisation is something I've liked the idea of doing for a while now. My main hesitation about it has been the risk of accidentally breaking anything, how to get it to work properly with composer/packagist/etc.

It makes more sense for the package to exist as part of the organisation in the long run, and looks more professional that way, as opposed to simply being on my account and outside the organisation. I just don't want anything to break, if breaking anything can be avoided. :-)

There are some other external services that the package is also tied into (e.g., SourceForge), but these should be quite easy to adjust (I think it's just a matter of changing a few webhooks and that's it).

3 months sounds like a good target, IMO.

[Maikuolan]

I'm thinking of starting with CIDRAM, and then moving onto phpMussel after CIDRAM has been transferred, due to that CIDRAM is a somewhat younger project, has less stars, forks, hooks, etc, so possibly a slightly smaller chance of things going wrong, or noticing when things go wrong, hopefully before anyone is bothered by it (not anticipating any significant problems in this regard, but need to start somewhere, and it's as good a reason as any for somewhere to start). Plus, now that v1.0.0 has been released, it's probably better to get it done sooner rather than later anyhow.

I'll need to sync a commit as part of the migration (for both projects), due to the front-end updater, references to old repositories, links to the old repositories in PHP header docblock comments and such (already have this ready, but I'll sync it when we're ready to migrate everything, to minimise any disruptions or confusion for others).

I could probably get this done by the end of the day, pending no unexpected problems occurring. Any reasons to delay that come to mind?

[DanielRuf]

Regarding point 1 (disable PR and issues), this should be just done at the fork which is then deleted after the sync back to the original repo which is then transferred to the org including the issues and PRs.

[DanielRuf]

Also updating links, composer.json and so on should happen on the original repo and the fork pulls these changes from an extra upstream origin wich points at the original repo (remember the two links about syncing forks).

I do not know how many external links may have to be updated but GitHub also creates redirects after the final transfer of the project like described in the first comment.

Generally we could start right now.

Fork it, do the changes in the original (source) project, pull the changes on the fork (in this case a PR would also be sufficient), test the project there (domains, GitHub pages, links, ...) and when everything points at the new address and the fork there looks fine, delete the fork and do the final transfer.

[Maikuolan]

Everything has now been moved, and all seems to be well, as far as I can tell.

How does it look on your end?

[DanielRuf]

Looks good so far.

Is Sensiolabs Insight configured to check the new repository?

[Maikuolan]

The other integrations seem okay, but the SensioLabs integration seems to have broken, I think; I tried adding the package as a new project, but SensioLabs can't see it / doesn't list it.

Maybe there's something that needs to be changed in repository/organisation settings or something?

[DanielRuf]

I guess you have to remove the old deploy key and remove the project from Sensiolabs Insight, readd it and add the new deploy key (I think this will produce a different deploy key and Sensiolabs probably warns that there is still the old one https://insight.sensiolabs.com/projects/e602f136-d1da-44b2-aee3-5a8394c0ad77 and the new one has maybe the old deploy key).

It looks like the new git source is linked but it still has the old (owner) name.

You may have to revoke their access at https://github.com/settings/applications and add them again using their wizard.

[Maikuolan]

Cheers; I'll give that a try and see how it goes.

[Maikuolan]

Hoorah! Revoking their access and adding them again using their wizard did the trick; Seems to be working correctly again now. ^.^

[DanielRuf]

Is there anything left or unresolved from the migration or can we safely close this issue?

[Maikuolan]

There's the possible Nitpick-CI issue (unsure if it's really an issue, but we can sort that out via the PR sent a little earlier; might actually be okay anyway, due to the PR not containing any PHP code in it; my first time working with Nitpick-CI, anyhow). Packagist, Gitter.im, SensioLabs, and SourceForge integration seem to all be fine at this point, AFAIK. I don't think there was anything else we needed to worry about, so, should be safe to close now, I think. :+1: