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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
