Note on 'systemd-216-9'

Wed Nov 5 03:52:48 UTC 2014

On Tue, Nov 04, 2014 at 06:09:35PM -0800, Adam Williamson wrote:
> On Wed, 2014-11-05 at 01:06 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Nov 04, 2014 at 02:06:21PM -0800, Adam Williamson wrote:
> > > On Tue, 2014-11-04 at 22:39 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > 
> > > > I understand that systemd git is not easy to follow, but I don't think
> > > > this differes that much from other fast-changing projects. If you take
> > > > a random kernel release, it's not like there's a nice lwn-style description
> > > > somewhere.
> > > 
> > > But there are actual releases. There's a kernel 3.17.1, and a kernel
> > > 3.17.2. They are artifacts with some sort of concrete presence, an
> > > announcement mail and a changelog (even though yes, it's just a git
> > > commit log).
> > Lots of things you say I agree with. Yesterday after you complained
> > that there the releases are not tagged in dist-git, I actually went
> > ahead and added tags for all post-F20 releases (haven't pushed them
> > yet).
> > 
> > The subject of point releases hasn't come up before. Actually I
> > haven't had *any* communication about the stable branches since they
> > were created apart from a few patches backported by other systemd
> > maintainers. If there are difficiencies, I need to hear about them.
> > I love working on Fedora, and I'm happy to fix whatever I can.
> 
> In the nature of things it tends to become most obvious around release
> times, because that's when it gets really painful when things break :)

> > Systemd has 213 open bugs in Fedora, + another 49 marked as RFC. I
> > pushed aggressively for an update in F21 to diminish this backlog a
> > little. Some of those bugs have fixes upstream, but because of the
> > large code reorganization that was done after systemd-208, lots of
> > patches can't be really backported and would have to be rewritten to
> > apply to the version of systemd that is in F20. This situation is
> > something that I want to avoid as long as possible in F21, and that is
> > why pre-release F21 updates were following upstream closely.
> 
> I can see what you're trying to do there, and there's merit to it, but
> it's best if it's carefully handled. Obviously there's a limit to how
> much you can do as one person, I understand that.
> 
> > I'm sorry about the timeout bug #1154768, it was my fault that it
> > landed in an update. We (upstream) knew about the issue, but I don't
> > think that anyone saw it as more than an annoyance, and that is why it
> > slipped through. Like I wrote before, that update *was* supposed to go
> > stable before the alpha freeze, and was supposed to go through all the
> > testing sufficiently early.
> 
> 10-14 was the date of the *Beta* freeze, not the Alpha freeze. Alpha
> freeze was weeks ago, on 08-26; this change landed long after Alpha
> shipped.
You're right, I was thinking about the beta freeze.

The policy for updates says "Pre Beta. This is the time between the
Bodhi enabling point and the Beta release. During this time we are
attempting to stabilize the major versions of software that will be
shipped with the final release of the OS. Major updates can be
tolerated, but breaking things for early testers should be avoided if
possible. Additionally, as we get close to Alpha or Beta releases any
change that breaks composes of Live media, install media or testing
should be avoided. Packages for Changes should be landing and getting
major testing. Avoid ABI/API changes where possible." Once again, I
apologize for the timeout bug, had I know that it will interact badly
with fedup, I certainly wouldn't have included it. Otherwise, I still
feel the update was withing the confines of the policy. The patches
that I pushed introduced some new features, but nothing which would
count as an (intentional) "major feature" or significant change in the
codebase, or ABI/API break. I used the versions in question on a few
different machines, and I wasn't aware of any significant problems
with them. Of course I didn't upgrade them using fedup, so I didn't
hit the one bug that caused problem.  If you look at the Fedora
bugzilla, the F21 version has *less* bugs than either the F20 and F19
versions.

> So what I'd suggest here is, at least in the conventional conception of
> a 'stable' branch, this is a change that should never have come close to
> one. It is clearly a feature addition, it's a substantial behaviour
> change, and it was not in response to any specific bug report (no,
> Lennart going 'hey, it's sure easy to push the power button on this
> laptop' doesn't really count as a bug report :>)
It's not about Lennart. Afaik he usually sticks to git HEAD and/or
rawhide. There are multiple reports about systemd entering an infinite
loop and I *thought* that this is a step in the right
direction. Systemd 217 was released with similar functionality, and
while it is now clear that this approach doesn't really solve
anything, the issues with it weren't clear at the time. The way I
understood the impact was "if your system hangs, it'll sync and
poweroff at some point." This change was pulled after testers reported
problems with it.

> It might really be a good idea to talk to the kernel maintainers about
> their approach here, as over the years they've got to a point where they
> strike a very decent balance between getting too far behind upstream
> development and introducing de-stabilizing changes downstream at bad
> times.
I'm very appreciative of the kernel promise of stability. But systemd
isn't at this stage yet, the codebase is much more in flux.

Zbyszek