Skip site navigation (1) Skip section navigation (2)

Re: BUG #4999: select 'a' < 'A' is true, but should be false . . .

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, ceccareb(at)talusmusic(dot)com, Brian Ceccarelli <ceccareb(at)talussoftware(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4999: select 'a' < 'A' is true, but should be false . . .
Date: 2009-08-24 22:07:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Mon, Aug 24, 2009 at 10:16 PM, Peter Eisentraut<peter_e(at)gmx(dot)net> wrote:
> Well, all you'd really need is that if you close a bug, you indicate
> that say via an email header
> X-PG-Bugs-Close: 12345
> and then spice up the archives display to show that somehow.  But the
> chances of getting people to use that consistently is pretty small.

If all it takes is adding one line to an email or cvs commit you were
going to write anyways, like in debbugs, I think it would be easy to
get buy-in. It doesn't change the workflow at all.

Where I think processes like bugzilla and the like fall down is that
it requires people to then go visit a web site -- essentially it
switches their whole process focus from their mail to the web site and
splitting between the two sucks.

> Some kind of simple request tracker where you just forward all bugs that
> you think need saving would also help.  You wouldn't need to copy all
> the follow-up there; it would only serve as a pointer into the archives.

I can't tell if you're basically describing rewriting debbugs or
describing something sucky like using Bruce's mailbox as a bug
tracker. We don't just want a pile of references to hundreds of old
mail threads that we have to go through later to figure out what's
still relevant.

It turns out you do need a _few_ bells and whistles. You want to be
able to merge tickets, set priorities -- if only to set all the
"wishlist" bugs to another category until someone adds them to the
todo or decides they're not good todos.

We don't want to spend our time wrangling bugs instead of fixing them
which is what bugzilla is designed for, but we do want to be able to
track the actual bugs. If you look at debian packages most of them
have only a half dozen or fewer bugs -- all the postgres 8.4 packages
combined currently has two normal and one wishlist bug for example.
That's because their workflow is a lot like ours -- when a bug comes
in it comes in by email and people are used to responding to emails
immediately. When the thread resolves you put a line in your email
saying to close the bug or refile it or whatever you need to do.

I think it's a conceit to think we always fix bugs immediately. Of
course the critical ones get fixed, but we've had plenty of bugs
reported that are known "would be nice" bugs that ought to be fixed
when we get a round tuit. Many of them have been dropped over time
because we just forget about them. Sometimes people raise them again
and we end up fixing them sometime, sometimes Tom pulls stuff out of
his archives because he gets a bee in his bonnet, sometimes we just
hope nobody notices. It would be useful to have a list of them if only
so when people report them we can say it's a known issue.


In response to


pgsql-bugs by date

Next:From: Peter EisentrautDate: 2009-08-24 22:38:37
Subject: Re: BUG #4999: select 'a' < 'A' is true, but should be false . . .
Previous:From: Peter EisentrautDate: 2009-08-24 21:16:30
Subject: Re: BUG #4999: select 'a' < 'A' is true, but should be false . . .

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group