Qmail
[Top] [All Lists]

Re: qmail Patch Repository

To: Qmail mailing list <qmail@list.cr.yp.to>
Subject: Re: qmail Patch Repository
From: Fabio Busatto <fabio.busatto@sikurezza.org>
Date: Wed, 28 Feb 2007 16:16:07 +0100
Delivered-to: sp-com-lists@consult.net
Delivered-to: gmail-qmail@securepoint.com
Delivered-to: sp.com.list@gmail.com
Delivered-to: mailing list qmail@list.cr.yp.to
In-reply-to: <45E59056.50008@cmcflex.com>
Mailing-list: contact qmail-help@list.cr.yp.to; run by ezmlm
References: <45E59056.50008@cmcflex.com>
Reply-to: Qmail mailing list <qmail@list.cr.yp.to>
User-agent: Mutt/1.4.2i
On Wed, Feb 28, 2007 at 07:23:18AM -0700, mlist wrote:
> Sounds like a great idea to me.  It would help if the patches were 
> categorized . . . I guess kind of like how squirrelmail has their 
> plugins section organized? http://www.squirrelmail.org/plugins.php

Yes, this is reasonable.
The idea is to create a system like the kernel, using a .config file
and a pool of #ifdef preprocessor directives.
I'm already working on a system to let the user to choose his patchset
with an interface similar to the kernel configuration process.
The user selects patch he is interested in, and the compile process
removes undesired code from the binary.

By the way each patch should be developed on its own, and one of my
principles for the project is that the code should no overlap if
possible (some patch behavior is unacceptable because it prevents
integration with other patches).
With this mood, each patch could be documented independently, and
categorized too (protocol enhancement, spam prevention, ecc..).

I'm waiting for feedback about collaboration (instead of starting a
new project with the same goal), and surely about the project name :)

Bye
Fabio

<Prev in Thread] Current Thread [Next in Thread>