-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
As the subject implies, I think we need a branch policy in the SSSD to address things like the recent security update that we released for 0.4.1. Currently there is no obvious way in the upstream tree to retrieve a safe copy of the 0.4.1 source to compile. You would have to be aware that the code tagged as 0.4.1 also requires cherry-picking a specific commit from the master branch to address a security bug.
Furthermore, we don't have a consistent definition about the components of our version string. I'd like to recommend the following policy for these two things.
Version components: Major version: Should reflect our current major goal. It will become 1 once we support all features necessary to replace nss_ldap, pam_ldap and pam_kerberos entirely. Minor version: These should represent feature-enhancement releases to the SSSD. For example, the major features intended in SSSD 0.5.0 will be support for the LDAP id backend and the Kerberos auth backend. Point version: These should represent bugfixes and security patches ONLY for the minor revision.
Branch policy: When the master branch has reached a point where we believe it to be ready as a new minor version (e.g. 0.5.0), we should tag that point (sssd-0_5_0) and create a new branch from that tag (sssd-0_5). Development should continue on the master branch. If there are fixes needed to continue supporting 0.5.x, they should be cherry-picked into the sssd-0_5 branch and tagged as 0.5.x+1. In the case of bugfixes, they can be queued up and released as a single point release when it is convenient. In the case of security issues, on the date of the embargo lift, these should be immediately merged in and a new point release generated.
Comments and criticisms welcome.
- -- Stephen Gallagher RHCE 804006346421761
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On Thu, 2009-08-06 at 10:02 -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
As the subject implies, I think we need a branch policy in the SSSD to address things like the recent security update that we released for 0.4.1. Currently there is no obvious way in the upstream tree to retrieve a safe copy of the 0.4.1 source to compile. You would have to be aware that the code tagged as 0.4.1 also requires cherry-picking a specific commit from the master branch to address a security bug.
Furthermore, we don't have a consistent definition about the components of our version string. I'd like to recommend the following policy for these two things.
Version components: Major version: Should reflect our current major goal. It will become 1 once we support all features necessary to replace nss_ldap, pam_ldap and pam_kerberos entirely. Minor version: These should represent feature-enhancement releases to the SSSD. For example, the major features intended in SSSD 0.5.0 will be support for the LDAP id backend and the Kerberos auth backend. Point version: These should represent bugfixes and security patches ONLY for the minor revision.
Branch policy: When the master branch has reached a point where we believe it to be ready as a new minor version (e.g. 0.5.0), we should tag that point (sssd-0_5_0) and create a new branch from that tag (sssd-0_5). Development should continue on the master branch. If there are fixes needed to continue supporting 0.5.x, they should be cherry-picked into the sssd-0_5 branch and tagged as 0.5.x+1. In the case of bugfixes, they can be queued up and released as a single point release when it is convenient. In the case of security issues, on the date of the embargo lift, these should be immediately merged in and a new point release generated.
Comments and criticisms welcome.
I would just adopt the same unwritten policy we used in FreeIPA. If we need to make a security release we branch and add patches on top of that branch. The branch is created out of the release tag. It is not necessary to branch at every release, only is we want to make an upstream security release not based on master. (Distributions can simply embed the patch in their packages if they are not shipping master).
Once we will reach version 1, we will evaluate if we want to have a stable vs development branch, in which case we will branch 1.0.x and there we will do only bugfixing while keeping development in master.
Simo.
sssd-devel@lists.fedorahosted.org
-
Simo Sorce -
Stephen Gallagher