Current status?

[Roberto C. Sanchez]

On Sat, Oct 21, 2006 at 10:05:33AM +0300, Fabian Fagerholm wrote:
> On Fri, 2006-10-20 at 22:57 +0200, Sven Mueller wrote:
> > Anyway, I agree with Roberto: The newer upstream release is surely the
> > better choice.
> [...]
> > Like Roberto, I would go for (2) though we should try to add and/or
> > update documentation as soon as possible.
> 
> I agree with Roberto, too: the newer upstream release is the better
> choice -- in principle. That's why I started this project ;)
> 
Glad we agree :-)

> But whether or not we *can* ship the new version in etch -- as opposed
> to "try" or "want" -- depends on making a working package, making it
> integrate with other packages, testing the package, testing the
> integration, working out an upgrade path, etc, and even then, the final
> decision is up to the ftp-masters and RMs.
> 
I still think it is possible.  Now, the packages have been in NEW for 1
day.  Is there anything we can do to speed their trip through the NEW
queue?

As far as an upgrade path, I think that is worked out by the dummy
packages quite well.  On the integration and testing with other
packages.  Have you cnotacted the openldap team to make sure that they
have an upload ready the day that cyrus-sasl-2.1 passes out of NEW?
AIUI, you said that once we are in experimental, a new openldap upload
happens and once it is built against the new cyrus-sasl-2.1, we upload
again *with* openldap support enabled.  Once all that is done, both
cyrus-sasl-2.1 and openldap get new uploads to Sid.

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.

> So our part is what it's been from the start of this project: work. :)
> 
Agreed.

> The other questions are related to quality, be it in the form of
> usability, reliability, maintainability, availability of documentation
> or anything else. As maintainers, we have to draw a line and say "this
> is the quality we are prepared to offer". Personally, I would set the
> quality requirements quite high, but as I said, the team decides -- and
> the team takes responsibility of that decision. That's all I'm saying :)
> 
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.

> And now, back to work :)
> 
Hey, email is work :-)

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-cyrus-sasl2-debian-devel/attachments/20061021/dabccbb9/attachment-0001.pgp