Walter Wong wrote:
> Part of the problem is that people are distributing binaries without
> the source code and all the docs are in the doc/ subdir of the source
> distribution.
>
Partly. And partly the docs don't provide a great beginners overview of
everything you need to know, but are more useful as reference materials for
those parts that are well documented.
There isn't a "documentation project" for Cyrus--the list serves as a
central repository for people to share their experiences, but the lack of
FAQs, HOWTOs, or overviews is a problem for those starting out.
Also, changes submitted to cyrus-bugs or developers don't always get applied
that quickly. I've had to resubmit three times over 9 months to get a
response before...
> I'm not sure what Sourceforge would add for us. I believe we've
> applied most of the documentation changes sent our way. We just
> haven't received much in the way of improved documentation.
>
I think it would add lots. Not just for a documentation project, but for the
whole Cyrus project. It would make it more of a community project rather
than a CMU project, which means more people getting more involved. It would
use a project management interface that more people are familiar with. It
would provide publically accessible bug/feature tracking.
> The drawback of sourceforge is that we either have our sources
> off-site or have to sync the two CVS repositories. We already have
> anonymous CVS access. We already have a discussion list.
>
While it is 'off-site' for those at CMU, it would be a lot more accessible
for those not at CMU. Currently there isn't much direct developer input from
people outside of CMU. This is probably a result of:
- Cyrus IMAPd popularity only really taking off in the last few months
- Lack of internals documentation
- Lack of a central project coordination point for all developers
If you moved across to SourceForge you get web-based CVS browsing (really
handy for developers getting involved the first time) and web-based list
archives that work (the current horde-based archive is slow as molasses, and
the IMAP-based archive requires a lot of resources (>9000 messsages!)).
Anyway, it would be a big step, but it might be time to start considering
it. I for one would love to get more involved in Cyrus, but currently I have
to nag the developers for personal help with understanding the internals
because the development is all 'behind-the-scenes'. If it worked like a
normal SourceForge project it would be easier to get involved.
> > The problem with the current situation is that:
> > 1- pwcheck is not widely understood
> > 2- pwcheck is not well documented
> > 3- there is no central repository of pwcheck daemons
>
> The current plan is to encourage people to write modules for
> saslauthd and contribute auth_<your mechanism>.c files since it has a
> better framework to allow for multiple, different authentication
> systems.
>
> Rather than doing stuff with pwcheck, I would encourage you to look at
> saslauthd and go with that.
>
Yes, I've started looking at saslauthd. I'll still get the pwcheck
repository up since there's no non-beta SASL that supports saslauthd, and
because people will take a while to convert. Also my pwcheck framework uses
a very simple Perl framework which will be much easier for many folks to get
going with than having to link in a saslauthd meth written in C. Further,
pwcheck allows people to easily customise their own special-purpose daemon
without getting it included in the main distribution.
