| Thread Previous • Date Previous • Date Next • Thread Next |
On Fri 04 Jan 2013 03:37:11 AM EST, Timo Aaltonen wrote:
Hi!
I'm requesting a MRE for SSSD. Upstream* generally supports several
branches at any time; one or two LTM (long term maintenance) branches
and the latest non-LTM stable branch. The current supported branches are:
1.5.x LTM
1.8.x LTM
1.9.x
(1.10 will be the next LTM)
There is no written policy about allowing only bugfixes on the stable
branches. Actually, 1.5.x did receive features upstream deemed
appropriate for it, but the other branches haven't. There is a
test-suite that is run during package build, but due to the nature of
the package it's impractical to cover every use case. The stable
releases are being tested by upstream and the community though (and
Fedora users which get the updates quickly, RHEL later), so giving a
few weeks after a release should reveal the regressions a release
might have.
SSSD is nowadays _the_ daemon for networked identity and
authentication, widely used in the enterprise and relied on by
Canonical support staff. There is an open MIR too, which will
hopefully be resolved sometime soon.
* https://fedorahosted.org/sssd/
FYI, speaking as the upstream representative:Since upstream is tied very tightly to RHEL development, you may assume the following rough policies (with the usual GPL disclaimer about lack of suitability for any specific purpose):
1) LTM releases will receive security updates (when applicable) for at least one year after the *second* LTM release that replaces it, or until that LTM release is no longer present in a supported RHEL release, whichever is *longer*. 2) LTM releases MAY include backported features from later branches if and when Red Hat decides those features are critical to customers. It is also possible that Red Hat may decide to rebase to a newer version of SSSD instead, as upstream generally tries not to break support at least to RHEL 5, though this will formally change with SSSD 1.10. [1] 3) Regressions in an LTM release branch are treated by upstream as a "drop everything and fix this" situation, considered nearly as serious as security issues. 4) LTM releases are generally better tested by QA staff, as they are usually driven by RHEL needs and therefore tested by RHEL QA. We're usually good at catching regressions quickly, but the more eyes on it, the better.
[1] https://lists.fedorahosted.org/pipermail/sssd-devel/2012-November/012616.html
| Thread Previous • Date Previous • Date Next • Thread Next |
