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.... -- 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/we... 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-reposito...
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