[Clo-devel] Proposed direction for common-lisp.net in 2015

[Erik Huelsmann]

Hi all,


Over the past months, I've observed a few issues with common-lisp.net in
its current state (none of them particularly new, it's just that I now have
taken the time to think about them):

 - Its way of becoming a "member" of the site is very archaic (writing to a
mailing list to ask for membership)
 - The site has adapted badly to the new era of DVCSes:
   Even for long-time users, it isn't straightforward how to publish new
git repositories in a way that web-browsing and http downloading are
supported
 - The site's services use a wide range of non-integrated applications
   * which need to be set up on every migration (every some 3 years)
   * easily break in some ways or others due to the sheer number of
different services and configurations
 - Some (many?) functionalities are duplicated - i.e. provided by multiple
services
   An example being Subversion and Git repository web browsing which are
provided by Trac and ViewVC/gitweb respectively

For a full listing of all currently available (end-user) services hosted on
the site, please see http://trac.common-lisp.net/clo/wiki/UserServices .

Concluding from the above, due to the evolutionary growth of the site, a
large number of services have been instated which are now blocking further
development of the site and even blocking the ultimate goals of the site by
blocking access for new-comers. Please note that some may argue that the
site needs very little maintenance. This is currently true due to the
nature of the activity on the site: there are hardly any new users and
hardly any activity in terms of new projects being created. The proposal
below tries to change that, meaning that maintenance of common-lisp.net
*will* require more work from the site/server's maintainers.


To address the problems identified above, I'm submitting the following
proposal about a new target infrastructure that makes the system both much
more user friendly as well as much more maintainer friendly.

 (a) Structure DVCS hosting by installing [http://gitlab.org/ GitLab]
     This would mean moving all Git repositories within the management
realms of this Git hosting management solution, empowering users to create
their own repositories, wiki's, ticket lists, projects, etc.
 (b) Stop supporting CVS repositories
     Repositories can be migrated to Git or Subversion, based on project
members' preference
 (c) Stop supporting Darcs repositories
     Repositories can be migrated to Git

By using GitLab, there's a single place for users to search and find all
git repositories hosted on the site. They can create their own, both as
projects and in their private (but not hidden) namespace. In addition to
this (searchable) structure, GitLab provides a consistent interface for
services that are currently not even supported (merge/pull requests,
commits review and snippets) or available separately (source browsing).

The idea is to continue Subversion support because we have active projects
using it and because it has HTTP support ("the modern web") as well as
active security support. Next to that, with Trac, we can come close to the
functionalities offered by GitLab -- a suite of functionalities I consider
"complete".


The list of changes above means the following benefits for the maintainers:

As a consequence of (a), we can:
  * Stop running gitweb
  * Stop supporting Trac's 'git' plugin
 --> GitLab includes repository browsing

As a consequence of (b), we can:
  * Stop running cvsd
  * Stop running ViewVC
--> Repository browsing for Subversion supported through Trac, Git through
GitLab

As a consequence of (c), we can:
  * Stop running darcsweb

The darcs, hg and cvs binaries will remain available on the common-lisp.net
machine, but their use will not be encouraged, nor will there be webbased
source browsing or other support.


Note that I'm submitting this proposal for discussion -- nothing is set in
stone and I'm soliciting your feedback. I'm aware that a more detailed plan
and especially timeline will need to follow. There isn't one (yet), because
I'd like to know your opinions on this first. Also, even if the feedback on
this proposal is positive, things are not going to change over night: the
installation of GitLab and the migration of repositories into it, will take
some time (especially for the development of the correct migration/seeding
scripts/programs).


I've asked your feedback, please start feeding back! :-)

-- 
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/20150206/b0d4e736/attachment.html>