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

[Lennart Poettering]

On Wed, 27.05.15 11:52, Martin Pitt (martin.pitt at ubuntu.com) wrote:

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

Sure, some of the udev breakage is more recent. But a good chunk of
the other stuff (gperf, EFI, path_is_mount_point()) is much older, and
some of it is easily visible...

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

Well, no.

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

However, "make distcheck" generates a tarball off the 220 git tree
just fine, if you had all the options enabled on a modern Fedora, like
I do.

Again, this is about testing options and combinations that are
not regularly covered by the core systemd developers. 

My release procedure involves not only doing "make distcheck", but
also then building the result in Fedora's koji, which then also involves
another "make check" run, as part of the RPM build process, on all
architectures Fedora supports. Only after that I tag a new
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...

Also, "make dist" worked fine as mentioned, hence altering this part
of the release process will not improve anything, but instead make
things even more sloppy...

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

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.

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.

Lennart

-- 
Lennart Poettering, Red Hat