[systemd-devel] Bugfix release(s)

[Lennart Poettering]

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.

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...

> 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...

> 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... :-(

Lennart

--
Lennart Poettering, Red Hat