Migration to salsa.d.o + git workflow

[Sébastien Villemot]

Hi all,

As you may know, Alioth is going to be shutdown on Feb 1st, 2018. This means that
we must migrate the team infrastructure (git repositiory + mailing list) to new
services (see [1] for more background on the Alioth shutdown).

This mail is about the migration of our git repositories (I’ll write another
mail about the issue of mailing lists).

The new host for git repositories is salsa.debian.org, which provides an
instance of GitLab (see [2] for more details).

I have created a group for the Debian Common Lisp Team (see [3]), and I have
added Peter, Christoph, Tobias and myself as owners. Please let me know if I
should add other DDs. For those of you who are not DDs, you have to create an
account on salsa, and request to join the group (see the Salsa documentation
referenced in [2]).

I am willing to do the import of all the team's repositories to Salsa.

But before that, I would like to take this opportunity to discuss the git
workflow used by the team. The current situation is in my opinion quite
unsatisfactory, because several different workflows are being used, leading to
confusion, mistakes and loss of developers' time.

Basically there are 5 dimensions in which git packaging workflows can differ:

1) The names of branches
2) The content of the upstream branch (whether it tracks upstream's git or
   tarballs)
3) The presence of a pristine-tar branch
4) The management of changelog entries (autogenerated from git commits before
   uploads or manually edited on the fly)
5) The tooling

Currently the team repositories are not consistent across dimensions 1) and 2).
Here is the current status of the main packages.

1) For branch names:
  + some packages use the standard git-buildpackage names ("master" for Debian
    packaging, "upstream" for upstream):
    sbcl, cl-asdf, ecl, slime, ffcall, cl-ppcre, cl-rt
  + one package uses "debian" for Debian packaging and "master" for upstream:
    stumpwm
  + some packages use a non-standard workflow (see [4]) with one branch per
    release:
    clisp (except for the last uploads), libsigsegv, cmucl

2) For the content of the branch tracking upstream sources:
  + some packages track upstream's git:
    sbcl, cl-asdf, libsigsegv, stumpwm
  + some packages track upstream's tarballs:
    ecl, slime, clisp, ffcall, cl-ppcre, cl-rt

For dimensions 3) and 4) there is consistency: the pristine-tar branch seems to
be used nowhere, and the changelog entries are generated on the fly.
For dimension 5), my assumption is that git-buildpackage is used everywhere,
except probably for those packages that follow the one-branch-per-release
scheme.

Additionally, there are quite a few other packages that currently don't have a
git repository, and whose information in Vcs-* fields is either inexistent or
wrong.


Given what seems to be the dominant practice both in the team, my proposal
for standardization would be the following:

1) Use the "master" branch for Debian packaging, and "upstream" for tracking
   upstream sources; when there is the need for an (old-)stable upload, a
   dedicated branch with the name of the release (e.g. "stretch") should be used
2) Store the tarball in the "upstream" branch
3) Use a pristine-tar branch: this is clearly a break with current team
   practices, but it makes cooperative work much easier; without that branch,
   when somebody else creates a new Debian revision (e.g. -2) while forgetting
   to run "uscan --force-download", then the upload is rejected because the
   generated tarball has a wrong checksum
4) For changelog entries, keep the current system (but make sure to use
   dpkg-mergechangelogs to facilitate merging of branches)
5) Use git-buildpackage

Note that there are other options. For example, the GNOME team has decided 1)
to use DEP-14 branch names, and 2) to track upstream's git in the upstream
branch (see [5] and [6]).

Please tell your opinion on this issue (i.e. if you value standardization
within the team and, if yes, which workflow), so that we can move on with the
Salsa migration.

Best,


[1] https://wiki.debian.org/Alioth#Deprecation_of_Alioth
[2] https://lists.debian.org/debian-devel-announce/2017/12/msg00003.html
[3] https://salsa.debian.org/common-lisp-team
[4] https://wiki.debian.org/Teams/DebianCommonLisp/GitPackaging
[5] http://dep.debian.net/deps/dep14/
[6] https://wiki.debian.org/Gnome/Git

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/attachments/20171228/4c5b5282/attachment.sig>