On Tue, Jan 15, 2019 at 01:09:16PM +0100, Lennart Poettering wrote: > On Mo, 14.01.19 11:26, Dave Reisner (d...@falconindy.com) wrote: > > > > > > Well, that sounds as if you want to volunteer as release engineer? ;-) > > > > > > Thing is, we are understaffed. I too have a wishlist of things I'd > > > like to see done, but with only two paid full-time upstream engineers > > > there's only so much we can do. > > > > Then, IMO, you have a fundamental misalignment. You're prioritizing > > feature work over stability, to the detriment of your customers. I > > Hu? By my "customers" I figure you mean RHEL customers? They don't use > the newest, hottest upstream systemd versions, but a stabilized > version that made its way through Fedora and the RHEL QA > processes. Production distros generally should handle it that way I > guess, not only for systemd, but any other project. > > Yes, we do feature work upstream, where else? > > > really don't think this would be a full time job. There's already a > > Well, fixing bugs is hard work. Release engineering means fixing > bugs. That's a lot of work, and I do a good chunk of it. Please, by > all means, join in, but don't claim it wouldn't be that much work. It > is! A lot! (And thankless work on top) > > > pretty good effort around tagging open issues which provides visibility > > to someone who might be in charge of cutting releases. And, much of what > > I'm suggesting is about *not* merging things after a certain point. > > Well, if you follow our commit history you'll see that quite often we > delay stuff until after a release. For example, right now #9762, > #10495 have been delayed from before the last release that way... > > Again. Step up if you want to have more systematic relase > management. You are invited! I'd very much appreciate if you do. > > > > If you (or anyone else in the community) would like to step up and > > > maybe take a position of release engineer, working towards a clearer > > > release cadence I think everybody would love you for that! I know I > > > certainly would. > > > > > > But additional work is not going to be done without anyone doing it... > > > > Like I said, it's a tradeoff. You currently have someone maintaining a > > stable branch in lieu of making your release snapshots more stable. > > It's not "me" who has that really. It's a group of volunteers doing > that, like a lot in Open Source. They scractched their own itches. If > you want a more strict cadence, the scratch your own itches, too, > please step up, like the folks doing the stable series stepped up! > > > > > Jun: 86 > > > > Jul: 276 > > > > Aug: 241 > > > > Sep: 317 > > > > Oct: 812 > > > > Nov: 882 > > > > Dec: 560 > > > > > > That it slightly misleading though, as a good chunk of those PRs that > > > good merged late where posted much earlier on, but only entered the > > > master branch late. So, most development work is definitely done at > > > the beginning of the cycle than in the end, but it's hard to see that > > > due to rebases/merges... > > > > This is all based on commit date, not merge date. It's not > > misleading. > > Well, we rebase all the time, it's not that easy... > > > > > Please, let's make all future systemd release better, not just the next > > > > 1 or 2. > > > > > > I certainly see the problem, but quite frankly, I don't see the > > > additional workforce for implementing a tighter cadence appear > > > anywhere... :-( > > > > It's really unfortunate that you're not willing to make any tradeoffs > > here. > > Well, I can tell you I will wholeheartedly support anyone stepping up, > and taking over release management. Otherwise we'll just keep trying > our best like we currently do, which isn't good enough for you. > > You know, I try to split my time between new work and bugfixing. I > simply don't won#t to get sucked into just the latter. > > We can certainly repriotize things and more often declassify bugs > hitting more exotic cases as release-crtical, in order to come to a > more strigent release cadence I.e. more aggressively ignore bugs with > exotic archs, non-redhat distros, exotic desktops, exotic libcs, weird > drivers, yadda yadda, and leave them to be fixed by community > patches. But I doubt that is in your interest either, is it?
I agree with Lennart here. We have a constant stream of bug reports coming in (yay, successful software, used in ever wider context), and if we decided to fix all bugs before doing feature work, we'd _never_ do any feature work. All of the top contributors already spend a significant chunk of their time doing fixes and cleanups and refactorings and adapting to changes in other components. If you look at the list of patches between v239 and v240, majority is bugfixes and refactorings. We could do this a bit more and then 100% of time would be spent on this, effectively switching to maintenance-only mode. This would be detrimental to our users, because those new features _are_ useful. So we need to strike a balance, and I think we do OK. 240 indeed has noticable issues. But the breakage is mostly a result of an attempt to clean up the udev codebase, not any feature development. Udev code is old and crusty, and any changes to it are risky. But by cleaning it up we just paying off acumulated technical debt. Anyway, people are asking for a release candidates to be posted. I'll start a seperate thread about 241-rc. Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
