Stable branches

[ncopa]

I wonder if it would make sense to have stable branches (or LTS branches) where we cherry-pick security fixes only?

By doing so it makes it possible to do patches releases in the future (eg 3.2.x or 3.4.x). But it is helpful even without patch releases, as it would be a common place for downstream packagers to share the work of backporting security fixes.

My self, as maintainer for Alpine Linux, would be willing to help maintaining such branches, and I believe we easily could get help for other distro maintainers as well. (Debian already does this work downstream, so they could as well just push their work upsteram?)

I believe it will be helpful with stable branches, even if we don't do that for every minor release (eg 3.4, 3.3, 3.2, 3.1). For example, if a distro needs backport a CVE to a 3.1.x release, it would be less work for them to base it of 3.2-stable than git master, as it is "closer" to their 3.1 release.

This will also make it easier for you to introduce new build time dependencies or change the way you build man-pages (I think it is correct to not include generated man pages in release tar balls) - without causing big issues for downstream who only need emergency security fixes.

[sudhackar]

I recently backported some of the security fixes to older releases on Ubuntu. Looks like we did a lot of redundant work - under the embargo, tests, backport and everything.

I agree on this count - as mentioned on discord by @tridge, we need more maintainers here. This feels like a right step in that direction

[charmitro]

+1 on this proposal. This would help solve several issues:

1. Reduce duplicate security backporting work across distributions (as @sudhackar mentioned about the recent Ubuntu experience)
2. Provide a clearer path for downstream packagers
3. Make the security fix process more efficient by having a common base closer to the target versions

I think starting with maintaining 2-3 stable branches would be reasonable to test the workflow without overextending resources. We could:

• Define clear criteria for what qualifies for backporting (security fixes only)
• Document the backporting process for new maintainers

[samueloph]

Chiming in from the Debian side:

I have been maintaining rsync for roughly 7 years on Debian and rsync has never required too much effort for its maintenance.

While I would certainly welcome stable series for rsync, I also acknowledge that it would not have a big impact in its maintenance burden right now.

If anyone needs to get the Debian packaging sources, they're here:
https://salsa.debian.org/debian/rsync

We use branch namespacing, so debian/master represents unstable/experimental and debian/$RELEASE_CODENAME for each Debian release, if there's not a branch for a given codename, it's because we have not pushed any changes after the Debian release.

Note: I plan to rename the debian/master branch to align with our new standard (https://dep-team.pages.debian.net/deps/dep14/), so in the future that branch might become debian/latest or debian/unstable.

I still think this is a good idea though, especially because the maintenance burden of rsync might quickly change if the project starts receiving bigger changes.

[samueloph]

I agree on this count - as mentioned on discord by @tridge, we need more maintainers here. This feels like a right step in that direction

What's this discord @sudhackar ?

[sudhackar]

What's this discord @sudhackar ?

It's an invite only discord server where tridge, WayneD, etc. are around.
Since I don't own the server - I'll leave it upto their discretion to invite others.

[charmitro]

It's an invite only discord server where tridge, WayneD, etc. are around.

Discord invitation was sent out to the rsync-announce1 mailing list when it was created.