Migration to salsa.d.o + git workflow

Wed Jan 3 21:51:25 UTC 2018

On Tue, Jan 02, 2018 at 03:19:46PM +0100, pvaneynd at debian.org wrote:

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

Ok, good to know.

> > 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
> 
> 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’…

I forgot to mention git tags in my proposal, but git-buildpackage creates a tag
for every Debian release. So the new branch for an (old)stable-upload would be
based on the tag corresponding to the Debian version currently in (old)stable.

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

The most convenient way of stripping DFSG-files is the "Files-Excluded:" field
in debian/copyright, when the latter is written in machine-readable format.
This field is understood by uscan (in conjunction with some special magic in
debian/watch for mangling the +dfsg suffix, see the uscan(1) manpage).

For an example, see debian/copyright and debian/watch in the slime repository
(which I am currently working on).

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

When a new upstream comes out, you run "gbp import-orig ${ORIG_TARBALL}" which
does two things:
- it creates a new commit on the upstream branch (and a new "upstream/$VERSION"
  tag)
- then it merges the upstream branch into the master branch

Then you can directly start the packaging work on the updated master branch.

There is no need to create a new branch or rebase anything. This workflow takes
full advantage of the merge feature of git.

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

I have never used it, but I think the workflow in that case uses 3 branches:
upstream (with full source), dfsg (the same as upstream, but without non-DFSG
files), and master (Debian packaging + DFSG-source).

Whena new upstream release is out, you first update the upstream branch, then
you merge the upstream branch into the dfsg branch, and finally you merge the
dfsg branch into master.

> > 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 guess you meant "to *not* upload". Of course, we should always update the git
repo when uploading. Note that there is a command recently added to
git-buildpackage ("gbp push", only available in the sid/testing version of
git-buildpackage) that simplifies the git push (it pushes all branches and tags).

> I also see no need for a commits ML…

Ack. The gitlab instance on salsa provides a subscribe-like feature which
basically achieves the same purpose for those who want to receive commit
notifications.

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

Yes, it will be shutdown on Feb 1st. I am going to send another email about
this.

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

Sure, once we agree on a workflow, I am willing to document it (with
command-line examples) on a wiki page.

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  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/20180103/ade6ded9/attachment.sig>