[Pkg-samba-maint] Target for squeeze: 3.4 or 3.5?

Steve Langasek vorlon at debian.org
Tue Apr 6 10:41:32 UTC 2010


On Mon, Apr 05, 2010 at 02:13:59PM +0200, Christian PERRIER wrote:
> Quoting Steve Langasek (vorlon at debian.org):

> thanks for explaining your position, Steve...

> > I haven't seen an upstream statement regarding the intended EOL of 3.4, but
> > extrapolating from past behavior - such as a security release for Samba 3.0
> > in October 2009, over 6 years after 3.0 was first released and a year and a
> > half after Samba 3.2 was released - I don't think there's much risk of the
> > squeeze release cycle (now + 3? 4? years) being affected by an upstream EOL
> > of 3.4 support.  Even if this were the case, all would not be lost for
> > security support for 3.4, since at least one other distribution - Ubuntu -
> > will definitely be shipping 3.4 in their upcoming release, so 3.4 will be
> > covered by downstream security support for 5 years.

> http://wiki.samba.org/index.php/Samba3_Release_Planning

> The main point are:

> - two major releases a year
> - when release N+1 is prepared, release N is current, release N-1 is 
>   in maintenance mode, release N-2 only gets security fixes and
>   release N-3 is discontinued

So Samba still supports installation on HPUX, but you only get security
support for a year before you have to switch to a new upstream series? 
Kinda ironic...

> Samba 3.5.0 has been out by March 1st 2010, which leads to assume that
> 3.6 could be out either in July (original release planning), or
> September....or even later.

> So, 3.4 would turn into security only mode as of September, which is,
> imho, the realistic date for squeeze release (if the freeze happens in
> May-June).

> And, starting on Spring 2011, we would be on our own for security updates.

The minimum length of time that Debian needs to support a package in a
stable release is around 2.5 years (1.5y between releases, + 1 year
overlapping security support); the maximum might be around 4 years.

If upstream is only providing security support for a given series for 12
months, then we're "on our own" for security updates for over half the
support cycle of the release, no matter which upstream version we choose.

However, if we go with an upstream version that other distros are also
shipping, then we can directly share patches with those distros.
Particularly in the case of Ubuntu, with the packages being nearly
identical, the patches can also be expected to work nearly identically in
all cases.

On the security side, I think that benefit outweighs losing 6 months of
security support at the front.  But this is just my opinion.


> So, by the time squeeze is frozen (latest news are late May or June),
> we will have at least a few 3.5 releases, which gives a realistic view
> that 3.5 will be even more stabilizing during the time we're preparing
> the freeze and, later on, during the freeze.

I think this overlooks one possibility - that 3.5 could turn out to be a dud
release, that will never be adequately fixed throughout its entire support
cycle, and that we wouldn't find out that this was the case until much
closer to the Debian freeze.

I don't say that this is likely, but I also don't know that it's impossible.
I would have preferred to see some comments about known good tests of 3.5
before a commit to trunk.

> My proposal becomes the following: we give ourselves a target date of
> May 25th to decide about our final choice for squeeze. It allows us to
> discuss with upstream at SambaXP as well as discuss together about
> this too..:-).

> So, as a consequence, we go for 3.4.8 in unstable before this (it is
> planned for May 11th), let it age enough to enter testing. We release
> 3.5.2 in the meantime to experimental.

> Would that be OK with you (ie "wait a little bit before uploading 3.5
> in unstable)?

That's ok with me.  In that case, we should immediately revert the 3.5 merge
into trunk so that we can continue maintaining 3.4, yes?

> As a end user, I have two reasons for pushing for 3.5 over 3.4:

> - better support for 64bit printing. This is definitely a killer
>   feature in these days where organisations are switching their
>   Windows systems to 64bit (mine is, the switch happening during 2010)

Hmm.  If we do decide to go with 3.4, I would like to look at the
feasibility of backporting this.

> - noticeably better ctdb support. Mathieu pointed this out and we
>   can expect ctdb-based setups to be come much more common.

Right - and that I fear will not be backportable.  So it's definitely an
argument in favor of 3.5.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20100406/b971ce9e/attachment-0001.pgp>


More information about the Pkg-samba-maint mailing list