Cyrus patches, cyrus patches. Get yer Cyrus patches here

[Bron Gondwana]

On Tue, 11 Sep 2007 10:36:35 +0200, "Fabio Pietrosanti (naif)" <lists at infosecurity.ch> said:
> Bron Gondwana wrote:
> > On Mon, Sep 10, 2007 at 02:38:07PM -0400, Ken Murchison wrote:
> >   
> >> A lot of the patches (past and present) have been implemented.  Some of the 
> >> others will be implemented in time.  Others may not.
> >>     
> >
> > Some of them are still waiting for me to finish polishing them as well!
> > In particular the pcreposix patch.
> >
> > Some of the others, like SIGQUIT support (still doesn't close down IDLE
> > connections at the moment...) we're still working at convincing Ken that
> > they're the right approach.  We'll be keeping them up-to-date with the
> > latest release, so people can always grab them if they want to be "beta
> > testers" of a new feature.
> >
> > Bigger things like statuscache, hashuser, commandtimer, folder limit -
> > they're at least protected by config options - but imapd.conf is already
> > getting pretty big for a basic sane setup.
> >   
> In my opinion a lot of configuration settings are very usefull and give
> users and system administrator much more flexiblity. Only look at the
> postfix software:
> mail-it-srv1:~# postconf  | wc -l
> 421
> 
> 421 configurations parameters available and still it's the best SMTP
> software ever.

Ahh, yes - Postfix.  I'm afraid I'm responsible for another one of those
not that long ago, MX record lookup for LMTP delivery (we wanted the
auto-retryness and preferential ordering of it for our internal redundant
lmtp spam and virus checking proxies with caching of bayes databases
for per-user-bayes in SpamAssassin).

We still maintain 5 patches again Postfix (actually, against Debian's
upstream package or it would have to be 6 patches!)  I really should get
back to pushing for a better TCP map equivalent module that can deprecate
it since Wietse seems to dislike it's never-quite-completedness.

> The good of postfix is that when someone has a need, within few months
> the specific features are getting committed to the main sources and the
> project grow in functionalities and flexibility.

It's true, and cyrus is quite similar in a lot of ways.  It really doesn't
bother us much as a site that's quite familiar with cyrus and has templating
tools to generate our configs.  It's more just that projects that grow over
time like cyrus end up with a bunch of defaults that are more for backwards-
(sometimes bug-)compatibility rather than being the most sensible value in
the common case.

> This is just my point of view about the feature enrichments of open
> source softwares. As soon as useful patches arrive, just give them a
> polished and the push it into the official sources.

That way also you see the Linux kernel with eleventy-million options (when
did you last run "make config" by hand, yikes) and most people not knowing
which knobs to twiddle.  Still, especially with "this features still
considered experimental" it is a good idea.

> I am following the Kolab project that's plenty of patches and now,
> slowly, are getting committed to the various opensource projects. If all
> patches was committed the first day a lot of more users could had the
> chance to use Kolab in a production environment with their own linux
> distributions.
> 
> I am not going to make a flame nor a trolling, just give my opinion on
> the external patches support importance in the opensource development
> model.

Thanks - I mostly agree, but Cyrus has already come a long way in accepting
changes from outside, and we do have to respect the central project's wishes
to move in a specific direction rather than hijacking it to become a giant
monstrosity that supports everybody, sort of.

The other issue is support - if we push code into Cyrus that later turns
out to be buggy/security problemy and there's nobody around who really
understands it that's a major headache for the project admins.  In the
FastMail patches case it's actually not too bad because we do have people
here using and willing to support those patches.  Rob and I talk over
just about everything so we both understand the code and can support it.

And yeah - I certainly agree that anything that's in the core project has
a much higher chance of adoption/use than something that's just floating
out there as a patch (sometimes if all the Linux distributions apply the
patch then it can become fairly "standard" anyway, and other people start
pulling their sources to become compatible.  That way leads to forks
though, and that's always more work)

Bron.
-- 
  Bron Gondwana
  brong at fastmail.fm