Starting unstable development, branching for etch

[Roberto C. Sanchez]

On Fri, Feb 23, 2007 at 12:17:02PM +0200, Fabian Fagerholm wrote:
> 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.
> 

Agreed.

> 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.)
> 
I generally don't have much time to mess with unstable.  However, I
maintain a few of my own backports and so I would like to volunteer to
lead this effort.  I will still contribute when I can to unstable
development, but I generally leave all of my machines (except perhaps
for one Xen domU) at stable.  Thus, things I might be able to contribute
to unstable won't get daily testing from me.  Hence why I would like to
focus on backporting and security.

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

Sounds good to me.

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/20070223/44a86b77/attachment.pgp