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