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

[Martin Pitt]

Lennart Poettering [2015-05-27 11:42 +0200]:
> Well, but let's not forget that a major part of the issues popping up
> actually were committed weeks ago.

Actually, no. As I said, on May 11 most everything was working just
fine, the udev regressions landed very late. The path_is_mount_point()
regression landed much earlier, but is much less visible (and now
there are tests cases with the patch I sent).

> Things like the broken gperf generated bits or the missing EFI dirs
> were in git since a loooong time.
> 
> It would be great if downstream could help us with testing many of the
> build combinations, at any time of the cycle, not just when it comes
> to a release.

Agreed. The "broken tarball" issues are not visible when building from
git (which is what I'm doing all the time). We didn't have that kind
of issues with 219 or 218 (or at least only negligible ones), but 220
taught us all that we need to test "make dist" builds more often.

So we have two indepenent things to fix:

 * Regularly test "make dist", as nobody does that  during regular
   development.

   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.

 * Impose a release freeze period with announcing an impending
   release, distros do a deep testing (this is a day's work for me, so
   can't happen that often). During that time (which really shouldn't
   be more than a few days) we really should avoid any commit which
   isn't an important bug fix, especially not large refactorings or
   new features.

Thanks,

Martin

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