Note on 'systemd-216-9'

[Adam Williamson]

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.

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 :>)

A stable branch is supposed to be, well, stable. It shouldn't suddenly
start introducing significant behaviour changes. The typical mindset for
maintaining a stable branch isn't 'let's pull everything that isn't
obviously dangerous' but 'let's not pull anything unless we have a
really good reason to believe it's a) needed and b) safe'.

I certainly see the argument for pulling more changes downstream than
would be pulled by following a traditional 'stable branch', but I'm not
sure the system of having a branch that's called a stable branch but
really isn't one which you suck straight into the downstream package
without any kind of 'filtering' step is the best way to go about that.

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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net