-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hey all, I'm in the middle of brushing up my understanding of how stable releases work in openstack. It seems we support two releases at the same time - Havana and Icehouse. For Icehouse, everything is clear - it gets all appropriate bug fixes, including performance improvements, security fixes, failure modes etc. For Havana, it's not that clear. As per [1], Havana is now in 'Security-supported' mode which is somehow different from 'Current stable release, security-supported' that is Icehouse. My understanding is that it means that only security fixes are allowed to go into the branch now. While we still see other types of patches being merged in stable branches. Those include performance improvements, adoptions to new third-party software, and other nice-to-have patches. My suggestion would be to allow only the following types of patches to old stable branches: - - security fixes; - - adoptions that fix major breaks with new versions of third-party software we depend on. So, what's our take on that? Is there any difference in how we consider patches for inclusion between multiple stable branches? Another thing that is not clear to me is who defines that transition between general stable branch state into 'Security-supported' one. Are there any written rules for that, like binding such transition to trunk milestones? Alternatively, am I putting too much in that distinction, and all kinds of stable branch appropriate patches belong to both of the branches? [1]: https://wiki.openstack.org/wiki/Releases Cheers, /Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTyQHbAAoJEC5aWaUY1u57La4IAMZvMzmMS4ajIWk78t0zR7O7 E/m08mP4pi9PZeuBpz1OUWagcr20Z04KabToPkunsrydeEBJsg/0+3PeZvC8Ndio Io9bJqpCdRsFPS0RN+JW8ad7mf1e1xENYpV1MWlJIq6VfZJdzshZE7ohmuDj3Qzo kUbqUJYQ4rH9NtXt6qGILNNjsUXByIeI8mfCYqqLxf0j8Al1RlYLeLo5yAn7Cf7S KF97qKx708nFYmaWMVDw5C1Vq6jgcLAL4BeKUVnDNaG6K5zqLfpzuu+9dqMY83HN KDUYgaR3fJSglbDfq++hr03tnUQUHo8YWxicztoeUQFx0P/RrKXd4NvbgNMw2uY= =xwVW -----END PGP SIGNATURE-----
Another thing that is not clear to me is who defines that transition between general stable branch state into 'Security-supported' one. Are there any written rules for that, like binding such transition to trunk milestones?
What is community supported is a function of resources available and historical experience with bitrot in N-1 branches, expanding the support scope for N-1 stable branch is fine if we can deliver it. We didn't have that written down, but traditionally when N is released it becomes "Current stable release, security-supported" and N-1 "downgraded" to "Security-supported" only. N-1 was going EOL around N+1 milestone3 but we have extended that to 15 months at last design summit. IIRC "current stable release" was originally defined by markmc as the branch where stable-maint team proactively proposes backports by monitoring the trunk, but we have lost that mode long ago, backports are now done retroactively after bugs are reported. To clarify, I propose following wording to be added to https://wiki.openstack.org/wiki/StableBranch#Releases When new OpenStack version is released it becomes "Current stable release, security-supported"" and previous version "Security-supported". "Current stable release" is the primary target for backports of bugfixes by the stable-maint team, other active branches may receive bugfix backports. "Security-supported" releases are target for the security fixes by the [[Vulnerability_Management#Supported_versions|VMT]] OpenStack Havana stable release will reach EOL at Juno (N+2) milestone-3 and stable releases starting from Icehouse will reach EOL 15 months after their release (approximately N+3 milestone-2). Cheers, Alan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 18/07/14 17:01, Alan Pevec wrote:
Another thing that is not clear to me is who defines that transition between general stable branch state into 'Security-supported' one. Are there any written rules for that, like binding such transition to trunk milestones?
What is community supported is a function of resources available and historical experience with bitrot in N-1 branches, expanding the support scope for N-1 stable branch is fine if we can deliver it.
So this does not mean any strict rules in terms of patches applicability, but instead a matter of initiative from interested parties.
We didn't have that written down, but traditionally when N is released it becomes "Current stable release, security-supported" and N-1 "downgraded" to "Security-supported" only. N-1 was going EOL around N+1 milestone3 but we have extended that to 15 months at last design summit. IIRC "current stable release" was originally defined by markmc as the branch where stable-maint team proactively proposes backports by monitoring the trunk, but we have lost that mode long ago, backports are now done retroactively after bugs are reported.
I like that lost mode. We could end up with persons assigned to specific projects that track master and backport relevant patches. This would reduce work to be done by downstream distributors. I will try to follow master development and make relevant cherry-picks for Neutron. Others can join on per-project basis.
To clarify, I propose following wording to be added to https://wiki.openstack.org/wiki/StableBranch#Releases
When new OpenStack version is released it becomes "Current stable release, security-supported"" and previous version "Security-supported". "Current stable release" is the primary target for backports of bugfixes by the stable-maint team, other active branches may receive bugfix backports. "Security-supported" releases are target for the security fixes by the [[Vulnerability_Management#Supported_versions|VMT]] OpenStack Havana stable release will reach EOL at Juno (N+2) milestone-3 and stable releases starting from Icehouse will reach EOL 15 months after their release (approximately N+3 milestone-2).
I've heard no objections to this, so I went to wiki and updated it with the text above.
Cheers, Alan
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTzjFaAAoJEC5aWaUY1u57650H/jktYxHmss/z2/4nzpGBUhSb IOGr7yZQze9S/vsWH6LNCP4sQ0UNk1SiURE25iBpNubfg96RBllMnT6SqZ5j1vVr cxosSxZ0JwKXiLW/CaQmPZR/eo/Afxj3QERmXqL+4tRKL+zPttqtMxsixyLfZPIt Lwv/SUksKyAPDqwZXLpTdkeM6tkjTYUmVqzp4/oL5954/xB6mbpONSO125Tso2G+ 6J9IEzldMPzp0t60AiHiXxFylrMXPjDubxT8Wq6GC7LEoZ4pT8kPSObiqk5lubK4 dCWQtNQRr3kMoqA6nVzV9W93bDRIehpkIqFhwpCsClhX81Og5b8ErUg3GYpYHQ4= =yk87 -----END PGP SIGNATURE-----
participants (2)
-
Alan Pevec
-
Ihar Hrachyshka