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
