Hi everybody,
As a follow-up to the changes that I proposed for
common-lisp.net to be implemented over the course of 2015 [
https://mailman.common-lisp.net/pipermail/clo-devel/2015-February/000161.html], I've been looking at the more detailed steps to be executed to implement the proposal. Remember that the changes are targetting a more modern, but also a simplified (for users *and* admins) system. It's an investment, but one in simpler maintenance while improving user experience. Currently, I'm thinking that the steps (no timing yet) should be:
0. Install a Code Commenting plugin on Trac to make it match the GitLab code commenting capabilities
1. Finish my experiments regarding the GitLab setup / installation
3. Run the migration to create all users and groups in GitLab
--> do we want all project which we know *don't* use Git to be created in GitLab too?
4. Import the CMUCL git repositories (using the script to be used for all projects)
5. Run a trial period of 2 months with Raymond Toy and CMUCL to iron out any unnoticed issues
6. Import the user's git repositories
7. Import all other projects with Git repositories
8. Turn off gitweb --> introduce rewrite rules to point to gitlab
9. Turn off git plugin for Trac --> introduce rewrite rules to point to gitlab
10. Turn off git-daemon (fully depend on https checkouts)
11. Convert all project darcs repositories to git
--> Notify all darcs project owners before we do about a planning/timing
12. Import the converted darcs repositories
13. Convert users' darcs repositories
--> Notify all darcs users before we do about a planning/timing
14. Import converted users' darcs repositories
15. Turn off darcsweb webbrowsing --> introduce rewrite rules to point to gitlab
16. Contact CVS repository owners to ask if they want to migrate to Subversion or Git
--> Which do we default to in case of no answer?
17. Convert CVS repositories to Subversion (where requested / defaulted)
18. Convert CVS repositories to Git (where requested / defaulted)
19. Import git-converted CVS repositories
20. Turn off ViewVC (Subversion & CVS) web-browsing --> introduce rewrite rules to point to gitlab/Trac
21. Turn off cvsd and related cron jobs
22. Turn off svnserve (fully depend on https checkouts)
"Import git repository" here means "move into gitlab space", which means the user will *only* be able to access the repository through GitLab's access methods (HTTPS and SSH(git user)) . Before we go to that step, we'll probably need to announce this step to all users who have git repositories in their home directories. (So they can object to the move -- if they do, the repository won't be moved, but we *will* scrap gitweb and git-daemon...)
Every step which says "Import" or "Convert" entails the creation (and testing) of a scripted procedure, as far as I'm concerned. Some steps will necessarily be executed in sequence. However some parts may be executed in parallel (e.g. contacting users about preferences and developing the scripted procedure). I'm hoping that when I sign up for this task, others pick up the rest of the work that relates to cl-net, such as fixing the mailing list archives or getting OAuth working for both Trac and GitLab (assuming we want that; do we?).
The order above is explicitly selected to benefit as soon as possible from having GitLab up and running, with namespaces reserved (hence the full group and user creation right at the start), but possibly unused at first (due to later imports of projects and repositories).
I'm not completely sure about steps 10 and 22; if we can make step 10 work, I'm inclined to research if we can keep step 22 as well.
So, judging by the number of steps to be executed, this may take all year, with one or two steps every month. I don't have a problem with that, though thought it'd be good to set expectations.
So, apart from the fact that it looks like an enormous amount of work, what are your comments? (Note that I see this as a consequence of years and years maintenance backlog; so, it's not something that I expect to be solved in a day or two.)
--
Bye,
Erik.
Robust and Flexible. No vendor lock-in.