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

[Lennart Poettering]

On Wed, 27.05.15 04:34, Michael Biebl (mbiebl at gmail.com) wrote:

> 2015-05-27 2:51 GMT+02:00 Dave Reisner <d at falconindy.com>:
> > The fact of the matter is, the last 2 releases of systemd have been
> > brown bag releases. Neither 219 nor 220 are useable as the tarballs are
> > provided. v220 doesn't even build in a large number of configurations.
> > v218 wasn't quite as bad, but landed 18 patches in Arch's packaging
> > before v219 was released. For the average Arch package, this is unheard
> > of, let alone being a *necessity* in order to make software useable.
> >
> > Please, let's figure out a way to lower the amount of work that gets
> > sharded out and duplicated by downstream packagers.
> 
> Glad to know that I'm not the only one who feels this way. Let me
> quote myself from #systemd:
> 
> <mbiebl_> zbyszek: looks like we want a v221 release soon
> <mbiebl_> fwiw, I think our QA for doing releases sucks
> <zbyszek> mbiebl_: I'm working on the selinux bug currently...
> <zbyszek> mbiebl_: I think the releases are possibly the point of
> highest instability
> <mbiebl_> a bit more official planning and giving people time to test
> would be a great start
> <zbyszek> I suggested doing a week of cooling off before a release
> before, but somehow that didn't stick.
> <mbiebl_> just telling people, when the release is planned, would help
> <mbiebl_> right now, that feels really amateurish
> <zbyszek> mbiebl_: yeah, that would help. But without a rule that only
> bugfix and cosmetic or documentation changes go in, it's hard to test
> stuff properly.
> <mbiebl_> absolutely, just saying that atm we don't even have that
> <mbiebl_> i.e. we know when a release is planned
> <mbiebl_> that's imo the absolute minimum
> <mbiebl_> the result is broken dist tarballs
> <mbiebl_> and distros having to ship 50+ patches until it get's usable
> <mbiebl_> that sucks bigs time

Well, but let's not forget that a major part of the issues popping up
actually were committed weeks ago. 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. Sure, I can notify a week before I intend to do a
release, but there's no reason to wait that long for testing! Upstream
git would ideally stay bootable and in a releasable state
all the time. And if it isn't, then this is something to fix
right-away, and not just when I sent out a notification..

We have a lot of build combinations, and I and the rest of the core
team only tend to test the upstream default config plus the Fedora
config. What broke are configs that are different than thes that could
have been caught weeks ago. We *rely* on downstreams to test these,
simply because the combinations explode...

Lennart

-- 
Lennart Poettering, Red Hat