On Mon, Jan 14, 2019 at 04:48:22PM +0100, Lennart Poettering wrote: > On Mo, 14.01.19 08:43, Dave Reisner (d...@falconindy.com) wrote: > > > On Mon, Jan 14, 2019 at 10:59:06AM +0100, Jan Synacek wrote: > > > Hi, > > > > > > since v240 didn't go too well, I would like to suggest that the next one > > > (preferably two) release(s) are bugfix only. Please, consider it. > > > > systemd needs better release hygiene, not just a smattering of bugfix > > releases. As a rolling release distro, we regularly find release-day > > blockers. That's bad for everyone. v240 was particularly bad as 6 months > > had elapsed since v239 (and over 3100 commits). That's the longest > > timespan and most commits in any systemd release in its nearly 9 year > > history. > > 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 really don't think this would be a full time job. There's already a 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. > 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 my understanding that there were known problems that prevented > > tagging the release of v240 sooner. If that's the case, most other > > development should have *stopped* with focus on fixing those problems. > > However, that doesn't appear to be the case. Looking at commit > > timestamps over time, nearly half the commits were made in the last 2 > > months: > > > > 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. > > Please bring back a regular release process (as dvdhrm attempted to do) > > like curl which has a 2 month release cycle. They're actually *beating* > > this 2 month period substantially, averaging 40 days between releases > > over the last 30 releases (2+ years). They follow a 30 day period of > > feature work with a 30 day period of bugfixes. > > > > Yes, this is probably more work. But maintaining the systemd-stable repo > > is work, too. Effort put into making releases cut from master more > > stable is ideally offset by the lack of work that will need to go into > > maintaining systemd-stable branches. > > > > 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. > Lennart > > -- > Lennart Poettering, Red Hat > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
