On 2-feb-2007, at 18:48, Aaron Stone wrote:
On Fri, 2007-02-02 at 12:24 -0500, [EMAIL PROTECTED] wrote:
On 1/31/2007, "Matthew T. O'Connor" <[email protected]> wrote:
So yes, imo also there's a very solid case for threads in
dbmail. But
like Aaron says, it will take some time to do this right.
Neither I nor
Aaron (afaik) have any experience with threads in C so we'll
have to
learn how to do it as we go along :-)
This sounds scary to me. Obviously it's not my project and I'm
not the
one coding, I'm just worried as an admin that depends on DBMail
that we
are going to open up a large can of worms for dubious gain.
I think the prudent thing to do in this case is to make sure that the
2.2.2 release is something that works very well and is quite stable.
The goal here is to give the dbmail community a IMAP/POP server that
will be suitable for their needs for some time to come in the future.
This will give the developers the time necessary to do everything
that
they need to do in order to get threads working right. And
without an
immediate crunch to fix some bugs or get a release out.
And then those of us who are more willing to take the newer
releases and
test them out can pick up the new 2.3x version as willing.
The damaging thing would be to start working on a threaded version
with a
large list of known defects in the existing release.
I'm going to save this one in my mental file under "smart project
management" -- you'd think it's common sense, but I think we've all
been
under that time crunch situation before that makes us think stupid,
not
sleep, and try to finish new and broken code instead of fixing old,
broken, but well understood code.
It is also damaging to have the next generation code remain broken for
too long before it really starts to work and show its value -- if
there
even is value, as some NG projects tank miserably -- so it's
definitely
a balancing act as to how many new things you can do at once.
Perhaps this would be a good time to call upon the dbmail constituency
and let the users democratically decide what needs to be done next.
We're using the Bacula backup software and I keep an eye on their
mailing
list. Recently, Bacula 2.0 was released. Subsequently, users were
allowed
to submit feature requests and/or other Bacula-related (sub-)projects
that
they would like to see developed in the next version of Bacula.
After a set time, a list of these proposals was compiled and the
users could
then cast a vote on their favorite projects, which lead to the
current TODO
list for the coming months
See also:
http://www.bacula.org/?page=vote
http://www.bacula.org/?page=projects
I think this a smart way to interact with the userbase of an (open
source)
development project and assures that the work the developers are doing
is both welcome and needed.
Of course, this implies that the developers should not be too proud
to "take orders"
from the community :-)
Just a thought...
Leander
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
