Post by Dave Reisner Post by Lennart Poettering Post by Dimitri John Ledkov
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
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?
Post by Dave Reisner
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.
Post by Dave Reisner Post by Lennart Poettering
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
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.
Post by Dave Reisner
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
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
Lennart Poettering, Red Hat