[Pkg-samba-maint] (forw) Development policy decision: Branches

[Christian Perrier]

For those of you who don't follow -technical.

I think this decision by upstream is great. It will probably allow us
to hopefully easily convince Debian SRM that we can follow "minor"
upstream releases in Stable (and of course also during the release
preparation freeze).

Would such policy be adopted for 3.2, we could have 3.2.11 in Stable
right now (going through s-p-u) while we currently pick updates one by
one, mostly based on reports *we* get in Debian BTS.

At the end of SambaXP, I discussed that with Noèl and we examined the
Changelogs for post 3.2.5 versions where....it was quite obvious that
not all changes were suitable for a release in Lenny.

If upstream is stricter, we could then have the same policy than
postgresql where all minor upstream releases are sent to stable point
releases.


----- Forwarded message from Kai Blin <kai at samba.org> -----

From: Kai Blin <kai at samba.org>
To: Samba Technical <samba-technical at lists.samba.org>
Date: Sat, 25 Apr 2009 12:53:29 +0200
Subject: Development policy decision: Branches
X-CRM114-Status: Good  ( pR: 38.6818 )

Hi folks,

after SambaXP wrapped up in Göttingen, Germany, the Samba team got together 
and came to an agreement on how to deal with the different branches of Samba 
that currently are in git.

Current status:
---------------

Just to recap, we currently have a v3-0 branch, a v3-2 branch, a v3-3 branch, 
a v3-4 branch and the "master" branch where the new feature development is 
happening. As you probably noticed, this is pretty confusing to work with and 
painful to maintain, especially as various bug fixes are still being pushed 
to the v3-2 and v3-3 branches, while the v3-4 branch is in the process of 
being stabilized for a release and the usual development work is still going 
on on master.

In order to make the life easier for the developers, for our release manager 
and for everybody tracking these branches, we decided to go a bit stricter on 
what sort of changes can go into which branches, following up on the new 
branch layout we decided upon last year.

New policy:
-----------

Development of new features should only happen on master. Once our release 
manager (RM) decides a new release is ready, the RM will branch off a new 
release branch to stabilize the release code while still allowing more 
experimental work to continue on master.

The release branch should stabilize up to the release, receiving mainly bug 
fixes and minor changes. Then, once the release candidate is cut, the release 
branch is closed.

If a branch is closed, only bug fixes are allowed into the branch, according 
to the following procedure:

* Every bug that is to be patched in a closed branch needs to be associated 
with a bug report in bugzilla.
* The developer of the patch needs to convince at least one other developer 
that the bug is critical enough to be included in a closed branch.
* The RM applies the patch from bugzilla only if the patch has been signed off 
by two developers.


What this means for the current branches:
-----------------------------------------

v3-0	closed (security fixes only)
v3-2	closed (critical fixes only)
v3-3	closed (critical fixes only)
v3-4	open   (will be closed when v3.4.0rc1 is released)
master	open   (always open to development)

This information will also find a home on the Samba wiki soon.

Cheers,
Kai

-- 
Kai Blin
WorldForge developer  http://www.worldforge.org/
Wine developer        http://wiki.winehq.org/KaiBlin
Samba team member     http://www.samba.org/samba/team/
--
Will code for cotton.



----- End forwarded message -----

-- 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20090425/43b859ae/attachment.pgp>