[Pkg-samba-maint] News about backports

[Christian Perrier]

Quoting Steve Langasek (vorlon at debian.org):

> 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.

Of course. It is meant to be kept specific to 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.

Agreed also.

upstream for bpo will be branches/samba/upstream because of bpo's
policy to track what's included in testing (not unstable, indeed)


> 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.)

For that matter, I was mostly motivated by needing some of these
backports on servers at work, where it's currently out of question to
switch to lenny in a near future, but for which we need some features
bringed in 3.2 series (such as a better RID backend handling).

So, as I was anyway working on this, I thought it wouldn't be that a
bg problem to share the resulting packages..:)


> > 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.

I haven't read anything implying that 3.3 would be development
series. Upstream has, TTBOMK, switch to a development model where 3
branches are kept in parallel.

> 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

The point of waiting was mostly to avoid having to go through the
lenny-proposed-updates in case something hardly needed for lenny would
be mandatory before the release. In that, I mostly followed the
release team recommendations.


> release freeze should at this point prevent us from moving forward on
> maintenance of the samba packages for sid/squeeze.

Yes, but nothing urges us to do so. After all, this is a matter of days...

> 
> > - 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)?

It is suitable.....but there might be users wanting to stick with 3.2
anyway, at least for a certain time (you know, big production servers
where any "big" change gives the admin teams big headaches....).

> 
> 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.


We'llm see if that's sustainable....but I feel that being able to
allow users to choose/test some more recent versions (for instance
when they encounter bugs which we have no setup to reproduce and first
try to reproduce them with more recent versions) might bring us some
help in tracking/dealing with some hairy issues we might have.

Not usre if my point is really clear, indeed.....hopefully you'll get
it..:-)


-------------- 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/20090210/b9ab8980/attachment-0001.pgp