[Clo-devel] Follow up to "proposed direction for common-lisp.net in 2015" -- the steps

[Erik Huelsmann]

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
2. Install GitLab on common-lisp.net (under the gitlab.common-lisp.net domain?
or should we prefer git.common-lisp.net?)
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.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clo-devel/attachments/20150213/8c3706eb/attachment.html>