[Twisted-Python] Suggested plan for GitHub migration

Amber "Hawkie" Brown hawkowl at atleastfornow.net
Mon Nov 30 07:49:41 MST 2015


Hi Craig,

Thanks for this, sharing your past experience is invaluable :)

I've gone through and thought about it a bit, and rewritten it into https://github.com/twisted-infra/braid/blob/git-migration-plan/gitmigration.rst -- it is basically your plan, with some added notes about Twisted Infra specific parts. I've skimmed over the specific details, since I feel that going too in-depth in such a plan will just be wasted effort as unknown issues arise, but with enough structure that we have a clear set of overarching goals for each step.

The migration will have a handful of policy changes that we will have to resolve -- such as ensuring that all merges have a topfile -- which aren't possible under a GitHub based system. I think these issues will just involve a lot of scrutiny and double checking during the transitional period until we are confident that we are enforcing our existing quality and process standards.

If anyone has any suggestions, or any more invaluable experience to share, please do :)

- Amber


> On 18 Nov 2015, at 07:48, Craig Rodrigues <rodrigc at crodrigues.org> wrote:
> 
> On Tue, Nov 17, 2015 at 8:57 AM, Adi Roiban <adi at roiban.ro> wrote:
> 
> For now, the funds were raised to migrate to GitHub, so we can not use
> them to do other things.
> 
> We will stay on Trac for issues... at least for now.
> 
> I have no idea how we can migrate to any issue tracker without losing
> data if we don't have full access to the database.
> 
> It is possible to migrate to another issue tracker and not lose
> data.  I've done Trac -> Redmine, and it works, but there was an existing migration
> script I could use.
> For migrating to a cloud based bug tracker, you would need to take every user
> in the existing Trac database, and see if there would be a way to map
> the existing users to the cloud database, such as GitHub.  It's a lot of work, but possible.
> However, for the scope of this project, if staying with Trac for issues is what is required, that is fine.
> 
> 
> We don't plan to migrate to GitHub Issues / GitHub Wiki / GitHub Pages
> 
> 
> OK.
> 
> So based on what you have listed, I would say that most of the work will be
> working with Git post commit hooks.
> 
> I would say the plan should be something like this.
> 
> A.1  https://github.com/twisted/twisted will be the "repository of truth"
>        for Twisted.
>            -> Twisted releases will be done from GitHub
>            -> the Twisted developers who are now "core committers" for SVN, must be
>                given access to be "core committers" to https://github.com/twisted/twisted
> 
> A.2  On the Trac server, a local git mirror of the GitHub must be set up.
>        Every bug tracker I've seen that integrates with git needs a local mirror of the repo
>         in order to parse the git history in order to update the bug database.
>         This mirror should be read-only, and the only thing updating this repo should be the Trac GitHub plugin.
> 
> A.3  On the Trac server, this plugin must be installed: https://github.com/trac-hacks/trac-github
> 
> A.4  On the GitHub server, a post-commit web hook must be configured.  The workflow will be this:
> 
>            [core committer does push to https://github.com/twisted/twisted]
>              -> [post commit GitHub hook will be called to poke the Trac GitHub plugin]
>              -> [Trac GitHub plugin will update the local git repo on the Trac server]
>              -> [Trac GitHub will parse the git history for new commits and update tickets]
> 
> I would recommend that steps (1) - (4) be made to work in a staging environment, with a separate
> GitHub repo, and a separate copy of the Trac database.  That way, you can test things out without derailing
> Twisted developers.  When you are confident that this workflow works, then the transition plan will be something
> like the following.
> 
> B.1   Send an e-mail to the mailing list and pick one day for the maintenance window.
>         This will warn folks when they should take a holiday from Twisted work. :)
> 
> B.2   When maintenance is about to begin, send a [HEADSUP] mail saying that repo will be unavailable.
> 
> B.3  Create Subversion pre-commit hook to disable all commits to
>          Subversion:
>               http://stackoverflow.com/questions/2411122/how-to-freeze-entire-svn-repository-to-make-it-read-only
> 
> B.4  Set up steps A.1 - A.4
> 
> B.5  Verify that B.4 works.  Have someone (Glyph?) do a commit to https://github.com/twisted/twisted, and
>          make sure that Trac works.
> 
> B.6  Once the Twisted core team are satisified that everything works, send an e-mail to the mailing list
>         that the maintenance window is over, and GitHub is now where the action is!
> 
> B.7  Update all wiki documentation to change all references to getting code from Subversion,
>          to getting code from GitHub.
> 
> B.8  Update all systems which used Subversion to use GitHub.  For example, buildbots.
> 
> --
> Craig
> 
> 
> --
> Craig
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/twisted-python/attachments/20151130/98a88eae/attachment.sig>


More information about the Twisted-Python mailing list