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

[Lennart Poettering]

On Tue, 26.05.15 17:57, Reindl Harald (h.reindl at thelounge.net) wrote:

> 
> Am 26.05.2015 um 17:29 schrieb Lennart Poettering:
> >On Tue, 26.05.15 16:39, Reindl Harald (h.reindl at thelounge.net) wrote:
> >>which shows that a important project like systemd playing on the same level
> >>as the linux kernel *just needs* point releases, there is a reason that the
> >>kernel has point-releases and not only for the latest and greatest version,
> >>systemd as well as the kernel are not a random webbrowser
> >
> >There's a stable git tree maintained by Zbigniew, Lukas and friends,
> >that carries backports for the stable releases. Most vendors should
> >consider following that repo I figure.
> >
> >I try to help the backporting business by tagging the commits I
> >personally consider backport-worthy with "git notes" and the
> >"Backport:" field
> 
> it just works poor
> 
> * https://bugzilla.redhat.com/show_bug.cgi?id=1185278
>   never got fixed in F20 but is fixed in Fedora 21

Well, it's not really a bug. We require util-linux to be around. If
you make it unavailable then you get to to keep the pieces. It's that
simple.

> * https://bugzilla.redhat.com/show_bug.cgi?id=1185277 open for
>   months

I wasn't aware there was a reproducer for this issue now. Good to
know.

> and in general a bunch of git commits don't replace a upstream changelog of
> a minor release where as user you never have any idea what your current
> installed package really is.

Nah, this is not how this works. We simply do not provide turn-key
ready versions of systemd. systemd is not an app, it needs to be
integrated by the distributions, and they will have to adapt it to
their needs. Hence: if you want minor release information check the
RPM changelog, but don't expect that from us. We are not a product, we
are just a building block others may build a product from, and thus
need to polish it.

> with a 220.1 and a usptream download of 220.1 containing a changelog things
> are entirely different (besides that the version numbers for a project
> existing just a few years are strange to say it nicely)

Well, I certainly have enough things to do. We have trouble keeping up
with he amount of work that we already get, and I have no intention to
make things even more complex by maintaining multiple branches for
you, if the distros already do this anyway.

And again, there's already the stable tree maintained by Zbigniew and
friends. It comes with a change history "git log" and it's constantly
updated. Zbigniew doesn't tag releases in it, but if that's what you
need you can just tag it yourself and count each commit up that is
applied based on a stable branch...

Lennart

-- 
Lennart Poettering, Red Hat