[systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Martin Pitt]

Hey Lennart,

Lennart Poettering [2015-05-27 12:26 +0200]:
> >  * Regularly test "make dist", as nobody does that  during regular
> >    development.
> 
> Well, no.

You just said before that we (distros) need to check tarball
generation/build more often. So I'm a bit confused by the "no" (but
see below).

> I use "make distcheck" regularly during regular development, and
> that's how I generate the final tarball.

True, the auto-generated header bug wouldn't have helped if I were to
do it on e. g. Debian sid and then build packages from that very
tarball, as it stemmed from being autogenerated from different kernel
includes etc.

So in that case the only thing that would have discovered this was
distros testing a tarball that you generated. So, back to "RC tarball,
plz test" a few days before you want to release?

> >    Alternative: Stop shipping "make dist" tarballs altogether and just
> >    tar the tagged git snapshot. Given the amount of patching that most
> >    distros do, we pretty much all run autoreconf anyway (including
> >    Fedora), so not having the pre-generated autoconfiscation and
> >    pre-built manpages etc. in the tarball isn't actually that much of
> >    a deal.
> 
> Well, while I sympathize with the idea, this is still not how most
> current distros work...

OK. It was just a thought for completeness.

> How about this: please run automated tests if you have them in regular
> intervals, always tracking git. And a few days before a release I'll
> notify the mailing list.

Sounds good. I actually did this twice (not sure if you saw my IRC
pings about that) I just didn't do it at the "right time". I think
this would have helped to find most issues indeed (except for the
keys-from-name.gperf thing, but meh -- happens seldomly enough), so
let's try this for 221!

> I really don't want to drown development in "deep freeze" phases, that
> are then alternated with "crazy merge time" phases. Instead, I'd much
> rather increase the release frequency, keep a steady stream of changes,
> and ask downstreams for more help with testing and keeping git
> constantly in a releasable state.

Also sounds good. With getting rid of a few large patches (like the
chkconfig → update-rc. ones, or the man page paths), doing CI more
often on my "distro" side will also become a much less manual process.

Thanks for having this post-mortem discussion, this is useful!

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)