Migration to salsa.d.o + git workflow

[pvaneynd at debian.org]

Hello all,


> 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 can login to the group and can see the others members :).

> 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.

+1

> 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.

FYI: I use git-buildpackage even in cmucl and friends. I have to use options to
set the upstream and debian branch.

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

Love having a good proposal from somebody who knows what he is doing!

> 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

Sounds good, but how will we know which commit we should use to create the
branch on? The commit messages often go ‘prepare for release’, ‘this time
for real’, ‘preparing again for release’…


> 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

Sometimes we need to remove non DFSG files. How would we handle this? I
guess that even for the normal workflow there is some handy command to
automate this?


When a new upstream comes out, what do we do with ‘master’? Do you merge
the new upstream? Do you archive the master branch and start a new one,
based on the new upstream?

> 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]).

I used to track git but then I encountered:

- upstream restarting git repositories (this was a while ago)
- problems removing non DFSG files from the git repositories

I guess there are fixes for the last problem?

> 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.

Could we also agree to now upload without pushing the code to salsa?
This was a problem I’ve hit in the past :(

I also see no need for a commits ML…

Apropos mailing lists: what to do with
pkg-common-lisp-devel at lists.alioth.debian.org <mailto:pkg-common-lisp-devel at lists.alioth.debian.org> ?
I gather that this is also going to go away?

All in all I can 100% find me in your proposal, but can I humbly ask for
some ‘howto’ commands so that I’m more certain that I’m not messing up?


Best regards, Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/attachments/20180102/32730ce1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1003 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/attachments/20180102/32730ce1/attachment.sig>