Re: anna_1.68_source.changes ACCEPTED into unstable
Hi,
Cyril Brulebois <kibi@debian.org> wrote:
> Hello,
>
> Here are some answers. Feel free to (re)organize them in a wiki page
> under the DebianInstaller namespace. :)
If have documented the l10n-uploading procedere on the wiki, to be found at
https://wiki.debian.org/DebianInstaller/Uploading
Holger
> Holger Wansing <hwansing@mailbox.org> (2018-08-10):
> > Yes, and I didn't read anything about that in the several
> > packaging/uploading docu. So that's mostly best practice, but no
> > strict packaging rule or the like?
> >
> > Also, I don't know anything about tagging. So, I need to know
> > something more about this tagging:
> >
> > When do we use it?
> > Just for every new uploaded version, as it seems...
> > More circumstances, where to set tags?
>
> I think most if not all packaging teams create tags when they upload a
> given revision of a source package; this even existed prior to git! :)
>
> This makes it possible to identify what revision of source code was
> (probably, no absolute guarantee) used to create a given package,
> which limits the need for downloading entire history of source
> packages using debsnap and friends.
>
> > Which tags do we use? The lightweighted or the annotated ones?
> > Looking at the existing tags, it seems that's annotated ones, but
> > without GPG signatur. Right?
>
> I tend to use this when releasing:
>
> git commit -am 'releasing version $copied_from_changelog'
> git tag -sm 'tagging version $copied_from_changelog' $copied_possibly_adapted_from_changelog
>
> If you don't have a GPG key handy (but then how would you debsign your
> upload?), you might want to use “git tag -am” instead of “git tag -sm”,
> which indeed creates an annotated tag, which still contains meta data
> like the tagger, a message, etc.; except for the GPG signature part.
>
> Interesting points:
> - you can mention the real/complete version in there;
> - you can verifiy the GPG signature if you ever doubt the repository
> (remember we have rather broad access with many many users on
> alioth first and on salsa now);
> - “git describe” doesn't use lightweight tags by default, one needs
> to pass “--tags”, so annotated/signed tags are better for that as
> well.
>
> What about those versions?
> - $copied_from_changelog: hopefully self-explanatory :)
> - $copied_possibly_adapted_from_changelog: there are special
> characters that can be used in Debian version numbers, but cannot
> be used directly in git (like ':' and '~'), so we have to adjust
> for those.
>
> Examples for ':' include apt-setup, busybox, tzsetup; depending on the
> habits of the person who uploads them, the epoch part (N:) is
> sometimes removed entirely (there can be a single version in the
> Debian archive of a given package, regardless of the epoch part,
> anyway). Usual replacement character is '%'.
>
> Examples for '~' include all packages we backport using the usual
> scheme: $unstable_version~deb9u1. Usual replacement character is '_'.
>
> People might use git-buildpackage which has some tagging options,
> but I tend to find the command line overly long, and it prefixes
> tags with a debian/ string, which we doesn't really make sense in a
> d-i context since most packages are Debian-specific anyway. We could
> arguable ship a configuration file in all packages, but I'm not sure
> we need more administrativia…
>
> Maybe we should just have a tagging script in the scripts/ directory?
> I used to use “xsf-tag” in the X Strike Force:
> https://salsa.debian.org/xorg-team/debian/xsf-tools/blob/master/xsf-tag
>
> What do you think?
>
>
> Cheers,
> --
> Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
> D-I release manager -- Release team member -- Freelance Consultant
--
============================================================
Created with Sylpheed 3.5.1 under
D E B I A N L I N U X 9 " S T R E T C H " .
Registered Linux User #311290 - https://linuxcounter.net/
============================================================
Reply to: