Stephen Frost <sfr...@snowman.net> writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> ... but I do agree with this. With our current methodology there's >> not a lot of need to decide a-priori whether something is a feature >> or a bug (in particular, the way it's categorized in the CF app is >> not a high-stakes decision). I think that's just as well.
> If we intentionally avoid making a distinction between features and bug > requests then it seems to follow that we feel bugs are no more important > than new features, and I have a seriously hard time with that position. I am not arguing for that at all. Rather, I'm pointing out that the real decision is currently made pretty late in the process, eg by the committer who decides whether to back-patch or not. I'm afraid Peter's right that a separate queue for bug fixes would encourage gaming the system by putting debatable stuff into the bug-fix queue. Now, if we can easily shove stuff back and forth between the main queue and the bug-fix queue, maybe that's not such a big deal. But it doesn't seem like the current CF app is really amenable to that; doesn't it for example want to leave an entry behind when you move something to another CF? > What we do have, from what I've seen anyway, is an issue where people > don't put things into the CF because they don't want to add "new" things > to the currently open CF, since it has already "started", and putting a > bug fix into the "next" CF would mean no one is going to be looking at > it for a month or two, which is pretty obviously confusing for people > who are used to the responsiveness provided on -bugs. I concur that this is a problem. On the other hand, putting something into the CF app already implies that you're not expecting it to get dealt with right away... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers