Starting unstable development, branching for etch

[Fabian Fagerholm]

Hello everyone!

We were one of the packaging teams that did actually meet the Release
Team's schedule for etch (more or less, at least ;), and all of us have
now had a well-deserved break.

Now I think it's time to starting moving again. There's a lot to
improve, and the etch version of our package was really only a first
practise round for this team. We pulled the package up to current Debian
standards. Now it's time to push beyond that.

Therefore, I've created an etch branch in our SVN repo [0,1]. That's
where any further etch development is going to happen. It's the place
from which you can pull the etch source to make a security fix (at least
they should be committed there), a point release, a backport etc.

(Backporters wishing to work on an etch backport are welcome to join the
project. We can make an etch-backport branch for you to work in. Mail me
your alioth id, and I'll add you to the project.)

[0] svn+ssh://svn.debian.org/svn/pkg-cyrus-sasl2/cyrus-sasl-2.1/branches/etch
[1] http://svn.debian.org/wsvn/pkg-cyrus-sasl2/cyrus-sasl-2.1/branches/etch/

Meanwhile, unstable development will be going on in the trunk as usual.
There's now no reason to hold off commits -- but do remember to keep the
trunk buildable at all times and test things as much as you can before
committing.

The unstable development will likely focus on better integration as well
as improving the reliability and quality of SASL itself. By integration,
I mean things like supporting multiple instances of saslauthd (including
chrooted ones) with different configs, improving both the packaging and
documentation to benefit sysadmins, and making sure that SASL plays
nicely with all supported authentication sources. Improvements in the
code quality is about tracking down those nasty segfaults and memory
leaks, and submitting patches upstream.

So now is the time to go hunting for test systems! We're going to need
people with different kinds of hardware that can set up a system to test
SASL on. There are many combinations that we need to be able to try;
some common pieces of software that people use SASL with are Cyrus
IMAPd, Postfix, and Exim. Some people use saslauthd, some use an auxprop
mechanism to connect SASL to a data store. Some store their
authentication data in a PAM-accessible store, some in LDAP, some in
MySQL and others in PostgreSQL. Yet others have Kerberos setups. When we
get a bug report, it will be much easier to debug if we can replicate
the user's environment and reproduce the bug. Also, taking notes while
setting up one of those combinations can be an invaluable starting point
for better documentation.

Let's get development rolling again, and do file wishlist bugs to track
the features you'd like to see in SASL (and be prepared to cook up a
patch as well ;).

Thanks,
-- 
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/20070223/6f04187c/attachment.pgp