[systemd-devel] Bugfix release(s)

[Dave Reisner]

On Mon, Jan 14, 2019 at 04:48:22PM +0100, Lennart Poettering wrote:
> On Mo, 14.01.19 08:43, Dave Reisner (d at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel