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

[Lennart Poettering]

On Tue, 26.05.15 20:51, Dave Reisner (d at falconindy.com) wrote:

> On Tue, May 26, 2015 at 04:17:07PM +0200, Lennart Poettering wrote:
> > On Tue, 26.05.15 15:12, Dimitri John Ledkov (dimitri.j.ledkov at intel.com) wrote:
> > 
> > > Or will there be a v220.1 release shortly with releasy fix-ups?
> > 
> > Well, we don't do point releases in systemd. 
> >
> > In systemd git we already have now the change that makes sd-bus and
> > sd-event public APIs, hence v221 is going to be more than just
> > bugfixes. 
> 
> Is git revert not an option? Does someone depend on this already, making
> a rollback impossible (and why would you allow that)? You say that
> versions are "just a label", but a project which adopts semver would be
> able to create a branch in git and produce a dot release with backported
> bugfixes. Surely you're familiar with this concept -- your colleague
> Karel does this routinely with util-linux.

I have no idea what you are talking of. I don't know what "semver" is
supposed to be? Fedora knows no package by that name. A typo?

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

Well, they do work fine in the Fedora build, which is what I
test. It's a pretty comprehensive test. And the release also does work
fine on FEdora. How I know that, because I run the newest systemd
versions exclusively myself, and I do watch some bugzillas.

I can only encourage you to test git more frequently on Arch, and not
wait for the release to do this. 

As mentioned before, the gperf and EFI issues you are apparently
referring to have been around since a few weeks. They do not appear
with the config options we use upstream or the ones of Fedora. We
*rely* on downstream testing this, otherwise this will *never* work.

Most software does not have as many options we have. Apparently we
have issues we keeping all combinations of the options working. There
are two solutions to this problem:

a) more testing of the combinations of options used by downstream. For
   this we'd have to rely on downstream support though.

b) simply remove the options. i.e. remove configure switches, and be
   more aggressive with requiring current versions of libraries,
   kernel headers, kernels, and so on.

I am open for b), but I guess many people would certainly prefer us
not doing that.

If we'd follow b) then everybody would run things in the same
combination, and ew test this from upstream we can be sufficiently
sure that it will work for everybody else, too.

But for a) we'd need support from projects like Ubuntu or Arch: for
example, a Jenkins instance or so that builds systemd git continouesly
for those systems and boots them. 

We currently have Davi Strauss' Jenkins instance, and I am very
thankful for that, but this tests only one specific configuration of
things. If you want ArchLinux' configuration to be tested regularly,
then this means that ArchLinux would have to provide something in the
area, we can never do that from upstream.

> > Also, next week I'll be travelling and I doubt I will be able to
> > finish a new release by then. Maybe in the middle of June we can get
> > out a new release.
> 
> I'm sorry to hear this too. Please find someone else who's paid to work
> on systemd and teach them how to package releases. The current state of
> affairs absolutely sucks for downstreams. Currently, packaging systemd
> takes more of my time than all of my other packaging responsibilities
> combined.

Well, I see noone volunteering unfortunately.

Like most Open Source project we are understaffed. I wished it wasn't
that way, but that's how it is.

> At LPC in New Orleans, you asked me how you could make systemd easier to
> work with on the downstream side. I told you that I wanted more frequent
> releases. You seemed amenable to this, but it really never happened.
>
> I'm asking again: can we have more frequent releases? Can you take the
> steps to actually make this happen and not gate releases on your own
> personal availability?

Oh yes, I'd like 3 week cycles, too. And I'd like to pass release
management to somebody else, because I am unhappy with this too, and
the ridiculous amount of work this brings for me. 

However, this simply falls short due to limited manpower. We need
a skilled full-time person for this, and I don't see that growing on
trees unfortunately. 

Lennart

-- 
Lennart Poettering, Red Hat