Current status?

Fabian Fagerholm fabbe at paniq.net
Sat Oct 21 15:43:58 UTC 2006


On Sat, 2006-10-21 at 03:15 -0400, Roberto C. Sanchez wrote:
> I think that the RC bug situation is such that we still have a few weeks
> until freeze.  If we can make sure that the openldap people are ready to
> go at the drop of a hat, then we can moev quickly enough to make it into
> Etch.

I'll ask the openldap team what they think. Keep in mind that theirs is
no simple package either, and they might not be keen on this idea.
 
> I completely agree that we should set the standard high.  However, for
> the moment I am content to get something into Etch that may only be
> marginally better than what is there now. This stems from observation
> that I made earlier about us possibly getting stuck maintaining a very
> diffucult maintain package for another entire release cycle.

I'm not sure I understand what you mean by the last sentence. If our
package goes into etch, our work load will not decrease -- quite the
opposite. We will have to maintain the version in etch, by supporting
users and taking care of possible security issues in cooperation with
the security team. We might have to prepare roll-up versions for point
releases. In addition to that, we will have our development branch where
we continue to improve the package for the next stable release by making
uploads to unstable. So in this sense, we are already "stuck"
maintaining this package, because we are the team whose job it is to do
so.

Also, I detect -- and please correct me if I'm wrong -- a view of etch
that is a little flawed. The release of etch is a singular point in
time, but etch has a life span that stretches far into the future. It
seems to me that the argument "let's get this into etch" considers only
that singular point in time and fails to consider the life span of etch.
It's a lot of work getting this package into etch, but the maintenance
only begins at that point and requires many times the resources that
this initial work requires.

The point of this project is not just to produce a new Cyrus SASL
package, it's to *maintain* it, so that we don't fall into the same
situation as with the old package.

Ok, enough of this, I don't doubt that you agree with me, and the etch
question is really out of our hands in practise, anyway.

-- 
Fabian Fagerholm <fabbe at paniq.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-cyrus-sasl2-debian-devel/attachments/20061021/6371e01e/attachment.pgp


More information about the Pkg-cyrus-sasl2-debian-devel mailing list