[systemd-devel] Bugfix release(s)

[Lennart Poettering]

On Mo, 14.01.19 11:26, Dave Reisner (d at 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?

Lennart

--
Lennart Poettering, Red Hat