Re: [Dbmail-dev] [DBMail 0000166]: IMAP sort breakage in 2.0.3
All, Just as a note I never intended for this code to get back ported to 2.0, so I guess if you guys want to work it out that is cool, however my vote would be to remove it rather than fix it and have a patch on the side if someone wants to fool with it. Otherwise I think it is a waste of time to work on the code for 2.0 as it is limted by the parsing system and other issues people are improving on in 2.1. just my .02 -leif I'm putting the two strands of this thread back together ;-) ... On Tue, Jan 25, 2005, Leif Jackson [EMAIL PROTECTED] said: That US-ASCII isn't recognized at all means that a fallback is always used. I would be interested in seeing the command that SquirrelMail uses. Perhaps we'd be much better off replacing the tries-to-be-general _ic_sort with an actual hack -- one that recognizes specific SORT commands that we know we can implement and that we've seen used by clients in the wild. I thought about making it a specific hack but then I knew it would be a wast of time when we got to x.x version of dbmail with header cahcing where it can be done right. Anyway I agree with you guys, and say leave 2.0.x alone with the _ic_sort and just make a push to make it right for 2.1 ..etc. Tho latly I have been way to busy to help so you can ignore me if you want :) We're not getting to 2.1 anytime soon, and I don't want to leave this broken in 2.0 if we can make a sane set of workarounds. Which is to say, all of the strings that are recognized and then skipped because the code says TODO are essentially silent failures to perform the requested sort command. That's not OK. If we get a string that we don't have the SQL to handle, then we should give a suitable error message and allow the client to work around us. I tried that yesterday. Won't work even for ARRIVAL, because of the way the result set is constructed in db_search. But perhaps I was just being dense. Accualy paul you could do this with a search of the cmd string to set a key for reverse and then just tell my btree code not to re-order the mid's as it takes them in reverse to being with if I rember correctly. I'll start reading through this part of the code, as I've never done much work on the IMAP side of things. What I'd like to do is take a survey of the SORT command options, and then see what sort of SQL we can reasonably do, and then work backwards saying, We have SQL than can do X, Y and Z so we'll only accept SORT strings involving X, Y and Z. If the SORT string asks for Q, then we give an error. Aaron ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
Re: [Dbmail-dev] [DBMail 0000166]: IMAP sort breakage in 2.0.3
Aaron Stone wrote: We're not getting to 2.1 anytime soon, Not true. cvs-head doesn't have many, if any, regressions at the moment. It already has fixed a significant number of bugs that are marked as wont-fix for 2.0 If we make a concerted effort, 2.1.0 can be released in no time at all. In fact, I'd very much like to release 2.1.0 before I start depending on the header tables. Ilja, I'll prepare cvs-head for 2.1.0 release (tag dbmail_2_1_0_release) today. I just committed all remaining pending changes before 2.1.0 and will start testing with different clients before I do the actual tagging. Can you release later this week if I give the go ahead signal? and I don't want to leave this broken in 2.0 if we can make a sane set of workarounds. Since we've fixed all the major bugs in 2.0 I think the time has come to at least start thinking about putting 2.0 in maintenance mode. All I have to do is convince a guy named Aaron :-) Which is to say, all of the strings that are recognized and then skipped because the code says TODO are essentially silent failures to perform the requested sort command. That's not OK. If we get a string that we don't have the SQL to handle, then we should give a suitable error message and allow the client to work around us. I do agree here. Silent failures are not good. But they've also been in there since 2.0.0. I'll start reading through this part of the code, as I've never done much work on the IMAP side of things. What I'd like to do is take a survey of the SORT command options, and then see what sort of SQL we can reasonably do, and then work backwards saying, We have SQL than can do X, Y and Z so we'll only accept SORT strings involving X, Y and Z. If the SORT string asks for Q, then we give an error. Even knowing what sort of sql we can do given the 2.0 database layout is not enough. I think Leif will agree the sort code was not designed with even a semblance of full compliance in mind. It also leans too heavily on the search code to extract strict sort functionality from it. I'd say: leave it be. -- Paul Stevens [EMAIL PROTECTED] NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands___www.nfg.nl
Re: [Dbmail-dev] [DBMail 0000166]: IMAP sort breakage in 2.0.3
On Wed, Jan 26, 2005, Paul J Stevens [EMAIL PROTECTED] said: Aaron Stone wrote: We're not getting to 2.1 anytime soon, Not true. cvs-head doesn't have many, if any, regressions at the moment. It already has fixed a significant number of bugs that are marked as wont-fix for 2.0 What wont-fix bugs in 2.0 are resolved in 2.1 without header caching? If we make a concerted effort, 2.1.0 can be released in no time at all. In fact, I'd very much like to release 2.1.0 before I start depending on the header tables. Where 2.1.0 involves mostly cleanups and rewrites of the imap server? I guess I'm a little out of touch with just what's happened so far in 2.1 :-\ If we're still keeping with the Linux kernel-style version numbers, then 2.1.0 is a release only developers should be touching. Even if 2.1.0 is rock solid, I fail to see how that benefits regular users -- the current release plan on the wiki (albeit from Nov. 2004) says that you want to do header caching in 2.1.1. So a user who things, gee 2.1.0 is rock solid, I'll just use that will have to go right back to 2.0.x if there's a security release or other bugfix release, since going to 2.1.x might involve database changes. [snip] and I don't want to leave this broken in 2.0 if we can make a sane set of workarounds. Since we've fixed all the major bugs in 2.0 I think the time has come to at least start thinking about putting 2.0 in maintenance mode. All I have to do is convince a guy named Aaron :-) Just a quick look at the 2.0.4 wiki gives me the impression that 2.0 is in a combined bugfix / code speedup mode. Basically, the idea is that most people are on 2.0 now, and things are getting smoother and faster with each release. That's a good thing in my book! Which is to say, all of the strings that are recognized and then skipped because the code says TODO are essentially silent failures to perform the requested sort command. That's not OK. If we get a string that we don't have the SQL to handle, then we should give a suitable error message and allow the client to work around us. I do agree here. Silent failures are not good. But they've also been in there since 2.0.0. So what? You uncovered how bad this bug is by silenty recognizing US-ASCII, which was the cornerstone of c-client's SORT request. If a client requests ISO-8859-1, we recognize and silenty fail on that, too. We just happen not to have received a bug report from someone whose client issues the command SORT (REVERSE ARRIVAL) ISO-8859-1 ALL. It's a bug and needs to be fixed. I'll start reading through this part of the code, as I've never done much work on the IMAP side of things. What I'd like to do is take a survey of the SORT command options, and then see what sort of SQL we can reasonably do, and then work backwards saying, We have SQL than can do X, Y and Z so we'll only accept SORT strings involving X, Y and Z. If the SORT string asks for Q, then we give an error. Even knowing what sort of sql we can do given the 2.0 database layout is not enough. I think Leif will agree the sort code was not designed with even a semblance of full compliance in mind. It also leans too heavily on the search code to extract strict sort functionality from it. I'd say: leave it be. If you're saying that there are no valid arguments to SORT, then let's take it out of the capabilities. It's just by luck that no client is asking for something it actually relies on DBMail returning sane values for. We're offering to do this SORT thing, but all we give back is garbage. Why offer in the first place? Aaron
[Dbmail-dev] [DBMail 0000162]: dbmail-pop3d zombies galore..
A BUGNOTE has been added to this bug. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=162 == Reported By:xing Assigned To: == Project:DBMail Bug ID: 162 Category: POP3 daemon Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 18-Jan-05 01:44 CET Last Modified: 26-Jan-05 11:39 CET == Summary:dbmail-pop3d zombies galore.. Description: Belive this problem started with 2.0.3 dbmail-pop3d is creating a bunch of dbmail-pop3d zombie proceses that must be killed via kill -9 switch. I see a lot of the following in my mail log. serverchild.c,CreateChild: child_register failed Jan 17 16:29:16 mail dbmail/pop3d[19630]: serverchild.c,CreateChild: child_register failed as shown in ps: 19624 ?Z 0:00 [dbmail-pop3d] defunct 19625 ?Z 0:00 [dbmail-pop3d] defunct 19626 ?Z 0:00 [dbmail-pop3d] defunct I have 144 of these zombies at this very moment even though I just killed them all and restarted pop3d daemon a minute ago. Important Note: Setting trace=5 for pop3d ALLEVIATES the problem! Thus I cannot provide trace info here. Weird. I have duplicated this many times on my end before submitting this report. Here is my relevant dbmail.conf entires: [DBMAIL] # Database settings host=localhost user=postfix pass=postfix db=dbmail sqlsocket=/tmp/mysql.sock # trace level for dbmail-maintenance TRACE_LEVEL=1 [POP] EFFECTIVE_USER=postfix# the user that dbmail-pop3d will run as (need to be root to bind to a port1024) EFFECTIVE_GROUP=postfix # the group that dbmail-pop3d will run as BINDIP=* # the ipaddress the dbmail-pop3d server has to bind to, * for all addresses PORT=110 # the port number the dbmail-pop3d server has to bind to. NCHILDREN=5 # default number of POP3 handlers (each is a process) MAXCHILDREN=20# mac. number of POP3 handlers MAXCONNECTS=1 # the maximum number of connections a default childs makes TIMEOUT=31# the time (s) before the dbmail-pop3d should shutdown a connection which is being idle. RESOLVE_IP=no# if yes, the pop daemon resolves IP numbers to DNS names in the log POP_BEFORE_SMTP=no TRACE_LEVEL=1 == -- paul - 18-Jan-05 09:25 CET -- Xing, I recently changed the manage_stop_children code to fix bug http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=158. Could you please test the current 2.0 cvs code to check if that also helps in your case? -- xing - 18-Jan-05 11:47 CET -- Checked out the CVS branch and still have the exact same problem. Again the weird thing here is that the bug is completedly gone, when trace is set to 5 for pop daemon in dbmail.conf. My only theory based on the trace level difference is perhaps the trace=5 produces noticeable delays between thread/process forking which allow the system to work? Without the verbose trace, the server is trying to spawn way too fast? Just a wild guess. Extra info: I can reproduce this bug with trace=1 almost immediately upon pop3d startup each time. However, sometimes, the startup would be fine but after 3-5 minutes, all the childs get unregistered and the registering/failed attempts create the same zombie pool. So the problem not only related to startup. edited on: 18-Jan-05 11:47 -- sersop - 26-Jan-05 11:39 CET -- the same problem for dbmail-pop3d and dbmail-lmtpd on high load system Fedora Core 2 Linux 2.6.10 http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=001 SMP Mon Jan 24 14:01:32 YEKT 2005 i686 i686 i386 GNU/Linux Bug History Date Modified Username FieldChange == 18-Jan-05 01:44xing New Bug 18-Jan-05 09:25paul Bugnote Added: 539
Re: [Dbmail-dev] [DBMail 0000166]: IMAP sort breakage in 2.0.3
On Wed, 26 Jan 2005 09:54:09 +0100, Paul J Stevens [EMAIL PROTECTED] wrote: Aaron Stone wrote: We're not getting to 2.1 anytime soon, Not true. cvs-head doesn't have many, if any, regressions at the moment. It already has fixed a significant number of bugs that are marked as wont-fix for 2.0 If we make a concerted effort, 2.1.0 can be released in no time at all. In fact, I'd very much like to release 2.1.0 before I start depending on the header tables. Ilja, I'll prepare cvs-head for 2.1.0 release (tag dbmail_2_1_0_release) today. I just committed all remaining pending changes before 2.1.0 and will start testing with different clients before I do the actual tagging. Can you release later this week if I give the go ahead signal? No problem. We'll label this as a development release I reckon? cheers, Ilja
[Dbmail-dev] [DBMail 0000168]: 2.0.3 fails install on FC3 with --prefix set
The following bug has been SUBMITTED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=168 == Reported By:Dead2 Assigned To: == Project:DBMail Bug ID: 168 Category: installation scripts Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 26-Jan-05 12:39 CET Last Modified: 26-Jan-05 12:39 CET == Summary:2.0.3 fails install on FC3 with --prefix set Description: dbmail 2.0.3 Fedora Core 3 w/updates ./configure --with-pgsql --prefix=/usr/dbmail make make install *snip* /bin/sh ./buildtools/mkinstalldirs /usr/dbmail/lib /bin/sh ./libtool --mode=install /usr/bin/install -c libdbmail.la /usr/dbmail/lib/libdbmail.la libtool: install: error: cannot install `libdbmail.la' to a directory not ending in /usr/local/lib make[2]: *** [install-libLTLIBRARIES] Error 1 make[2]: Leaving directory `/usr/src/dbmail-2.0.3' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/usr/src/dbmail-2.0.3' make: *** [install-recursive] Error 1 Not all libraries get installed. This worked fine with dbmail 2.0.1. It never gets to install the sbins since it errors out before that. This is what does get installed in lib: # l -R /usr/dbmail/lib/ /usr/dbmail/lib/: total 1 drwxr-xr-x 3 root root 72 Jan 26 12:36 . drwxr-xr-x 4 root root 120 Jan 26 12:36 .. drwxr-xr-x 2 root root 592 Jan 26 12:36 dbmail /usr/dbmail/lib/dbmail: total 141 drwxr-xr-x 2 root root 592 Jan 26 12:36 . drwxr-xr-x 3 root root72 Jan 26 12:36 .. -rw-r--r-- 1 root root 32872 Jan 26 12:36 libauthdbmail.a -rwxr-xr-x 1 root root 853 Jan 26 12:36 libauthdbmail.la lrwxrwxrwx 1 root root22 Jan 26 12:36 libauthdbmail.so - libauthdbmail.so.0.0.0 lrwxrwxrwx 1 root root22 Jan 26 12:36 libauthdbmail.so.0 - libauthdbmail.so.0.0.0 -rwxr-xr-x 1 root root 32439 Jan 26 12:36 libauthdbmail.so.0.0.0 -rw-r--r-- 1 root root 15216 Jan 26 12:36 libpgsqldbmail.a -rwxr-xr-x 1 root root 860 Jan 26 12:36 libpgsqldbmail.la lrwxrwxrwx 1 root root23 Jan 26 12:36 libpgsqldbmail.so - libpgsqldbmail.so.0.0.0 lrwxrwxrwx 1 root root23 Jan 26 12:36 libpgsqldbmail.so.0 - libpgsqldbmail.so.0.0.0 -rwxr-xr-x 1 root root 17289 Jan 26 12:36 libpgsqldbmail.so.0.0.0 -rw-r--r-- 1 root root 8846 Jan 26 12:36 libsortdbmail.a -rwxr-xr-x 1 root root 853 Jan 26 12:36 libsortdbmail.la lrwxrwxrwx 1 root root22 Jan 26 12:36 libsortdbmail.so - libsortdbmail.so.0.0.0 lrwxrwxrwx 1 root root22 Jan 26 12:36 libsortdbmail.so.0 - libsortdbmail.so.0.0.0 -rwxr-xr-x 1 root root 11634 Jan 26 12:36 libsortdbmail.so.0.0.0 == Bug History Date Modified Username FieldChange == 26-Jan-05 12:39Dead2 New Bug ==
[Dbmail-dev] [DBMail 0000168]: 2.0.3 fails install on FC3 with --prefix set
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=168 == Reported By:Dead2 Assigned To: == Project:DBMail Bug ID: 168 Category: installation scripts Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 26-Jan-05 12:39 CET Last Modified: 26-Jan-05 13:51 CET == Summary:2.0.3 fails install on FC3 with --prefix set Description: dbmail 2.0.3 Fedora Core 3 w/updates ./configure --with-pgsql --prefix=/usr/dbmail make make install *snip* /bin/sh ./buildtools/mkinstalldirs /usr/dbmail/lib /bin/sh ./libtool --mode=install /usr/bin/install -c libdbmail.la /usr/dbmail/lib/libdbmail.la libtool: install: error: cannot install `libdbmail.la' to a directory not ending in /usr/local/lib make[2]: *** [install-libLTLIBRARIES] Error 1 make[2]: Leaving directory `/usr/src/dbmail-2.0.3' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/usr/src/dbmail-2.0.3' make: *** [install-recursive] Error 1 Not all libraries get installed. This worked fine with dbmail 2.0.1. It never gets to install the sbins since it errors out before that. This is what does get installed in lib: # l -R /usr/dbmail/lib/ /usr/dbmail/lib/: total 1 drwxr-xr-x 3 root root 72 Jan 26 12:36 . drwxr-xr-x 4 root root 120 Jan 26 12:36 .. drwxr-xr-x 2 root root 592 Jan 26 12:36 dbmail /usr/dbmail/lib/dbmail: total 141 drwxr-xr-x 2 root root 592 Jan 26 12:36 . drwxr-xr-x 3 root root72 Jan 26 12:36 .. -rw-r--r-- 1 root root 32872 Jan 26 12:36 libauthdbmail.a -rwxr-xr-x 1 root root 853 Jan 26 12:36 libauthdbmail.la lrwxrwxrwx 1 root root22 Jan 26 12:36 libauthdbmail.so - libauthdbmail.so.0.0.0 lrwxrwxrwx 1 root root22 Jan 26 12:36 libauthdbmail.so.0 - libauthdbmail.so.0.0.0 -rwxr-xr-x 1 root root 32439 Jan 26 12:36 libauthdbmail.so.0.0.0 -rw-r--r-- 1 root root 15216 Jan 26 12:36 libpgsqldbmail.a -rwxr-xr-x 1 root root 860 Jan 26 12:36 libpgsqldbmail.la lrwxrwxrwx 1 root root23 Jan 26 12:36 libpgsqldbmail.so - libpgsqldbmail.so.0.0.0 lrwxrwxrwx 1 root root23 Jan 26 12:36 libpgsqldbmail.so.0 - libpgsqldbmail.so.0.0.0 -rwxr-xr-x 1 root root 17289 Jan 26 12:36 libpgsqldbmail.so.0.0.0 -rw-r--r-- 1 root root 8846 Jan 26 12:36 libsortdbmail.a -rwxr-xr-x 1 root root 853 Jan 26 12:36 libsortdbmail.la lrwxrwxrwx 1 root root22 Jan 26 12:36 libsortdbmail.so - libsortdbmail.so.0.0.0 lrwxrwxrwx 1 root root22 Jan 26 12:36 libsortdbmail.so.0 - libsortdbmail.so.0.0.0 -rwxr-xr-x 1 root root 11634 Jan 26 12:36 libsortdbmail.so.0.0.0 == -- Dead2 - 26-Jan-05 13:51 CET -- dbmail_2_0_branch_26_Jan_2005.tgz works without any lib problems. Bug History Date Modified Username FieldChange == 26-Jan-05 12:39Dead2 New Bug 26-Jan-05 13:51Dead2 Bugnote Added: 570 ==
Re: [Dbmail-dev] [DBMail 0000166]: IMAP sort breakage in 2.0.3
Aaron Stone wrote: What wont-fix bugs in 2.0 are resolved in 2.1 without header caching? recent flag (bug #97) comes to mind. I know I said I would try to fix that one for 2.0, but that was before the sort breakage surfaced. Also, insertion will be more robust in terms of mime parsing because of gmime. Generally, there's not much difference between 2.0 and cvs-head yet from the client's point of view. Internally, things have changed quite a bit for imap and insertion. If we make a concerted effort, 2.1.0 can be released in no time at all. In fact, I'd very much like to release 2.1.0 before I start depending on the header tables. Where 2.1.0 involves mostly cleanups and rewrites of the imap server? I guess I'm a little out of touch with just what's happened so far in 2.1 :-\ Mostly imap stuff, yes. But like I said I'm also reshuffling the insertion code and I'm adding a lot of test-code. If we're still keeping with the Linux kernel-style version numbers, then 2.1.0 is a release only developers should be touching. Even if 2.1.0 is rock solid, I fail to see how that benefits regular users -- the current release plan on the wiki (albeit from Nov. 2004) says that you want to do header caching in 2.1.1. True. But before I move on the 2.1.1, I need a 2.1.0 release first right? So a user who things, gee 2.1.0 is rock solid, I'll just use that will have to go right back to 2.0.x if there's a security release or other bugfix release, since going to 2.1.x might involve database changes. The database changes I have in mind will be forward compatible. That is: 2.1.x code will use more tables, but 2.0.x will be able to use the same database without a problem. So people will be able to use both 2.0 and 2.1 connecting to the same database *at the same time*. I don't mind working on 2.0 when it comes to bugs. But with just two people actively working on the code at the moment, maintaining and actively moving forward two different branches just seems a bit much. Just a quick look at the 2.0.4 wiki gives me the impression that 2.0 is in a combined bugfix / code speedup mode. Basically, the idea is that most people are on 2.0 now, and things are getting smoother and faster with each release. That's a good thing in my book! agreed. 2.0 is definitely not abandon-ware. It's what all my clients use. I do agree here. Silent failures are not good. But they've also been in there since 2.0.0. So what? You uncovered how bad this bug is by silenty recognizing US-ASCII, which was the cornerstone of c-client's SORT request. If a client requests ISO-8859-1, we recognize and silenty fail on that, too. We just happen not to have received a bug report from someone whose client issues the command SORT (REVERSE ARRIVAL) ISO-8859-1 ALL. It's a bug and needs to be fixed. There's no discussion there. Just whether it should be targetted at 2.0. If you feel strongly about fixing it for 2.0, I say excellent. Perhaps you can find an elegant solution to this problem :-) If you're saying that there are no valid arguments to SORT, then let's take it out of the capabilities. It's just by luck that no client is asking for something it actually relies on DBMail returning sane values for. We're offering to do this SORT thing, but all we give back is garbage. Why offer in the first place? Because the SM users love it? -- Paul Stevens [EMAIL PROTECTED] NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands___www.nfg.nl
Re: [Dbmail-dev] [DBMail 0000166]: IMAP sort breakage in 2.0.3
Paul J Stevens wrote: Aaron Stone wrote: If we're still keeping with the Linux kernel-style version numbers, then 2.1.0 is a release only developers should be touching. Even if 2.1.0 is rock solid, I fail to see how that benefits regular users -- the current release plan on the wiki (albeit from Nov. 2004) says that you want to do header caching in 2.1.1. True. But before I move on the 2.1.1, I need a 2.1.0 release first right? Just to confirm (since I'm still unsure), you are saying that 2.1 is for development not production right?
Re: [Dbmail-dev] [DBMail 0000166]: IMAP sort breakage in 2.0.3
Matthew T. O'Connor wrote: Paul J Stevens wrote: Aaron Stone wrote: If we're still keeping with the Linux kernel-style version numbers, then 2.1.0 is a release only developers should be touching. Even if 2.1.0 is rock solid, I fail to see how that benefits regular users -- the current release plan on the wiki (albeit from Nov. 2004) says that you want to do header caching in 2.1.1. True. But before I move on the 2.1.1, I need a 2.1.0 release first right? Just to confirm (since I'm still unsure), you are saying that 2.1 is for development not production right? Absolutely!!! The whole 2.1.x series will be a development series, whereas 2.0.x will be for stable production systems. Until 2.2.0 happens at the end of the 2.1 drive. -- Paul Stevens mailto:[EMAIL PROTECTED] NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED] The Netherlandshttp://www.nfg.nl
Re: [Dbmail-dev] [DBMail 0000166]: IMAP sort breakage in 2.0.3
Paul J Stevens wrote: Matthew T. O'Connor wrote: Paul J Stevens wrote: True. But before I move on the 2.1.1, I need a 2.1.0 release first right? Just to confirm (since I'm still unsure), you are saying that 2.1 is for development not production right? Absolutely!!! The whole 2.1.x series will be a development series, whereas 2.0.x will be for stable production systems. Until 2.2.0 happens at the end of the 2.1 drive. Good, glad that has been made crystal clear :-) But I don't think you need a 2.1 release. 2.1 will just be CVS Head, it should probably be tagged 2.1 at some point, but we don't need (or want) a 2.1 CVS branch.
Re: [Dbmail-dev] [DBMail 0000166]: IMAP sort breakage in 2.0.3
On Wed, Jan 26, 2005, Matthew T. O'Connor matthew@zeut.net said: Good, glad that has been made crystal clear :-) But I don't think you need a 2.1 release. 2.1 will just be CVS Head, it should probably be tagged 2.1 at some point, but we don't need (or want) a 2.1 CVS branch. I was going to suggest a dbmail_2_1_branch, until the mantra main development happens on HEAD started to ring between my ears. So we'll just tag the 2_1_x release points along the way, and eventually we'll be stable and *then* we'll branch off with dbmail_2_2_branch before continuing new work in HEAD again. Aaron
