[Pkg-samba-maint] News about backports

[Steve Langasek]

Hi Christian,

On Tue, Feb 10, 2009 at 07:14:46AM +0100, Christian Perrier wrote:

> The only actions needed to backport our current stable packages are:
> - drop libtalloc-dev from the build dependencies
> - add "--without-libtalloc" in debian/rules

> Julien Cristau pointed me to the "libcups2-dev | libcupsys2-dev" build
> dependency that should be changed to "libcupsys2-dev" for Etch, as
> causing problems for some arches. I haven't thought deeper to
> this..:-)

This will affect official backports because they use the stock Debian buildd
configuration, which requires the first branch of any or'ed build-dep to be
satisfied, yes.

The lenny/sid branches shouldn't be changed to try to accomodate this
requirement.  If you want to provide bpo backports to etch, this change
should be kept on the backports branch.

> branches/samba/backports.org/etch in SVN with upstream versions kept
> in branches/samba/upstream.

However, branches/samba/upstream is meant to track the upstream version of
samba corresponding to trunk (unstable).  If the backports are going to
track what's included in unstable (which I believe is the policy for bpo),
then that's fine; if they diverge, the backports should have their own
branches/samba/upstream-$foo branch.

> "Unofficial" backports
> ----------------------

> I felt it would be good to also offer our users more "bleeding edge"
> versions of samba. Particularly, when one sees the changes in 3.2.6 and
> 3.2.8, it might be quite useful for them to use these packages
> preferrably over the official packages in either Etch of Lenny, or
> even the official backported packages from bpo.

> This is meant to be hosted at
> http://pkg-samba.alioth.debian.org/packages

> As of now, I created packages for lenny and etch, for samba 3.2.8, and
> only for i386.

> The version numbers are 2:3.2.8-1~unoff{40|50}+1. Even thouogh there
> is no 2:3.2.8-1 version anywhere, I felt it would be good to have
> something similar to bpo versioning scheme.

It's your prerogative to spend time on these if you want to, but I don't see
how there's any value in this and definitely won't be putting any work into
them (nor helping with any bug reports that result).  I think we should be
more concerned about getting samba updated in unstable, which is where I'm
going to focus my attention.

(For that matter, I have no interest in ongoing backports to etch, generally
- if users find that the software in etch doesn't meet their needs, they
should be looking at upgrading to the current Debian release instead, since
that will be lenny very shortly.)

> The future?
> -----------

> As soon as lenny is released, the plan for official packages is to
> upload 3.3.0 in unstable.

Is 3.3.0 recommended by upstream for general use?  I think I read a
discussion at one point about the plans for the various series, but I can't
find it now.  The "3.3" does imply "development series" to me, especially
after the jump from 3.0 to 3.2, but maybe I'm reading/remembering this
wrong.

If 3.3.0 isn't intended for general consumption, then it should stay in
experimental and we should continue tracking 3.2.

If it *is* intended for general consumption, then I don't see any reason to
wait for the lenny release before uploading it to unstable.  Nothing in the
release freeze should at this point prevent us from moving forward on
maintenance of the samba packages for sid/squeeze.

> - replace unoff packages by 3.3.* packages and forget about 3.2 ones
> - create a new unoff branch (unoff33?) for 3.3 packages and continue
> maintaining 3.2 packages in unoff, at least as long as upstream
> officially supports 3.2

I don't think it makes any sense to provide backports of a different package
version than the one we're shipping in unstable.  If 3.3 isn't suitable for
backports, that implies to me that it's not suitable for the next Debian
release - so why would we push it to unstable (and testing)?

Again, it's not for me to say how you spend your time, but I see this being
a major division of resources that doesn't help further the goal of
providing quality Debian packages to users.

Cheers,
-- 
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