Craig Rodrigues
2015-11-17 23:48:09 UTC
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 losethem 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.
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