[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stable branches (was Re: [PATCH 0/8] maintenance patches)

From: Bernhard Voelker
Subject: Re: stable branches (was Re: [PATCH 0/8] maintenance patches)
Date: Tue, 5 Jan 2016 15:56:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

On 01/05/2016 02:31 PM, Kamil Dudka wrote:
Fedora and RHEL maintainers backport mainly fixes for bugs that are reported
via Red Hat Bugzilla.  At the same time, we update to the latest upstream
release in the development version of Fedora, from which the stable Fedora
releases are branched each 6 months approx.

As an example, these are the findutils versions we currently maintain:

findutils-4.6.0  - in Fedora rawhide (the development version of Fedora)
findutils-4.5.16 - in Fedora 23 (released on November 3rd, 2015)
findutils-4.5.14 - in Fedora 22 (released on May 26th, 2015)
findutils-4.5.11 - in RHEL-7 (released on June 9th, 2014)
findutils-4.4.2  - in RHEL-6 (released on November 9th, 2010)

If there are "stable" branches for upstream findutils, I will be happy to
share any backports that apply, to make them available to other downstream
distributions with a similar release cycle.  If there is a linear history
only, it will also work for us.

Thanks for confirming.
At openSUSE and SUSE, we're doing the same - although we don't use a Git
repo (yet?) for maintaining the different branches for the various product
releases.  But the history of all branches is visible on OBS (Open Build

Rolling release (Factory/Tumbleweed):
openSUSE-42.1 aka "Leap":

Thus said, at {open,}SUSE we only need the linear history from upstream,
and cherry-pick patches for urgent issues into each project.
Furthermore, there might be downstream-only patches - actually there is
one at openSUSE to add an option -, so that there has to be such work
anyway.  Having an upstream maintenance branch therefore doesn't bring
much gain for openSUSE/SUSE.

Switching to upstream view:
I could imagine that others do it similarly to Fedora/Redhat/openSUSE/SUSE.
This means that we could save our time upstreams and only concentrate on
the master branch.
It maybe made more sense back in the times when bigger implementations were
done like FTS, which was considered "unstable" and therefore would have
blocked "stable" releases with nice little improvements and fixes.
I don't believe that we'll have such a situation in the near future.
IMO findutils _is_ "stable" and could switch to normal business by
doing 1-2 releases per year with moderate change rates, and no maintenance
branches.  Many other GNU projects do the same, e.g.:

$ for f in git://git.savannah.gnu.org/{coreutils,grep,wget,sed}.git ; do\
   echo $f:; git ls-remote --heads $f ; done
f25181d32c40f82ee26dea6de6b7f4b385352a14        refs/heads/fiemap-copy
7f154dcfc5641c9616921d4c5ac5005bcb2507eb        refs/heads/fiemap-copy-2
25e704ebf21c6fb002520beb08ebd9de2f0a2820        refs/heads/fiemap-copy-3
5171befcb122b12677f60715603be091625a9e08        refs/heads/master
6c935a055435623edb2b6b5451dc6ef815c9fb61        refs/heads/next
9aee8e78ea1d7966b5d79034874d9cf831565410        refs/heads/selinux
40ed879db22d57516a31fefd1c39416974b74ec4        refs/heads/master
b30500f0f499b8459c20dfc859ff7ac2180b6b34        refs/heads/master
af702340a1f3b462d0224968602c2b2974f218d6        refs/heads/parallel-wget
57cea296730bafb7d90eaa95fc03e12e44e9d0ab        refs/heads/tim/wget2
e168584d028e3afda789b710a52f993b6042e50d        refs/heads/wget2
61c0a53ec997e128fe5c976eda7412571409410a        refs/heads/master
4c0c33f6bb443fac4a244cba8935a2515d7453c6        refs/heads/ssed

Have a nice day,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]