On 30 November 2015 at 16:49, Amber "Hawkie" Brown <hawkowl@atleastfornow.net> wrote:
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.

[snit]

+1 for "master" as the main branch.

+1 for GitHub logins but I have no idea how we could migrate existing accounts.

This is more like a Git migration plan with main repo on GitHub, but I think that this should be the first step...and focus on this, before looking at PR and GitHub issues.

I don't see any note about the code browser and how to migrate narrative and apidocs source code links. 

The Internet is full of links like http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/web/http.py#L475

I think that tracext.github.GitHubBrowser only redirects changeset ... and from the docs only new changesets

I was hoping that as part of the git migration, we can implement a custom Twisted web resource which will handle all the redirections to GitHub code browser
 
Since Twisted trunk merges are not busy, I don't think that we need to worry to much about breaking the dev process... I am more worried about failing to gather the merges required to create the waiting/testing queue. 

--
Adi 

 


> On 18 Nov 2015, at 07:48, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
>
> On Tue, Nov 17, 2015 at 8:57 AM, Adi Roiban <adi@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@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python




--
Adi Roiban