Migration to salsa.d.o + git workflow
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  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  for more details).
I have created a group for the Debian Common Lisp Team (see ), 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 ).
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
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:
+ some packages use a non-standard workflow (see ) with one branch per
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
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
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  and ).
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
??????? S?bastien Villemot
??????? Debian Developer
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available