[systemd-devel] Bugfix release(s)

[Lennart Poettering]

On Di, 15.01.19 10:36, Filipe Brandenburger (filbranden at google.com) wrote:

> So I think all the bits already exist somewhere and perhaps a small
> change in naming would go a long way to make these pushes smoother.
>
> If when we cut v240 from the master branch, we had called it v240-rc1
> instead, perhaps it was clear that it could take some more testing
> before it was made official.
>
> Furthermore, fixes for the breakage were backported into the
> v240-stable tree in systemd-stable repository, so perhaps calling the
> top of that tree v240 (or v240.0) at some point would have been
> helpful.

Note that we don't branch releases right now. Instead when we are
getting closer to a release we simply don't merge PRs we don't
consider appropriate for the release anymore until after the
release. Or in other words: the master branch simply "stops" for a
while getting new stuff, and only gets bugfixes until we release the
version, which reopens the floodgates (well, usually, but for v241
we'll be a bit more conservative, and open the floodgates on v242
instead).

I am not convinced we should branch the new release, and let master
continue get new stuff. This just makes us loose focus I think, as it
means we'd in parallel allow new stuff in and do bugfixes, and I think
we should focus on the latter before the release.

(Of course, one can disagree with where we draw the line between
"bugfix" and "new work", i.e. what kind of stuff we merge and what we
don't, but that's a different question).

> Having been pushing to systemd-stable this week (fixing one of the
> CVEs in previous versions), I have to say that there's some impedance
> to contributing to that tree, since I needed a separate fork (GitHub
> doesn't want to let me do PRs from my main fork), sometimes it doesn't
> build on the latest toolchain and libs (I'm working on fixing that
> too), etc. Perhaps having some more of the distro maintainers actively
> helping on those branches would be best. I think bringing those
> branches into the main repo would help in those regards.

Hmm, I'd really like to keep that separate I must say, so that I only
see PR/issue notifications for the upstream branch, and not the stable
one. I am not sure I grok the GitHub issues you are having?

> As distros start to do heavier and broader testing of that
> pre-release, we start fixing bugs at trunk, backport them to
> release-v241 and after a week or so release v241-rc2. Rinse and
> repeat.

Well, but why do two branches for that? Why not just do all that in
master? This is what we currently do: reduce what we merge that isn't
a bugfix, and then open the floodgates again only after the release.

In general, I think it's a good thing if we don't have unnecessarily
many parallel versions in the wild. For example, you want that the
version that is going to be released is also the version the upstream
devs run. If you'd suddenly split that in two, then the upstream devs
would immediately live in a different world than the "stabilized"
version...

Lennart

--
Lennart Poettering, Red Hat