Re: Add a "Known Issues" section - Mailing list pgsql-hackers

From Robert Treat
Subject Re: Add a "Known Issues" section
Date
Msg-id 200601011850.59230.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: Add a "Known Issues" section  (Qingqing Zhou <zhouqq@cs.toronto.edu>)
List pgsql-hackers
On Sunday 01 January 2006 17:30, Qingqing Zhou wrote:
> On Sun, 1 Jan 2006, Tom Lane wrote:
> > Qingqing Zhou <zhouqq@cs.toronto.edu> writes:
> > > Do we have a "known issues" section somewhere? If not, I would suggest
> > > we split the TODO list into two big sections, one is the PostgreSQL
> > > improvement part, the other is the known issues part.
> >
> > Aren't they all "known issues"?  You need to be a lot clearer about what
> > distinction you intend to draw, and why it's so important that it
> > deserves to be the principal classification metric for TODO.
>
> If I believe "Terminators" will dominate the world in a predicatable
> future, I will draw a clear distinction here.
>
> "Known issues" means bugs or something beyond your expectation -- but
> "bug" itself by definition is "functional". For example, if a program
> crashes, you can say it is bug or it is not a bug totally by your
> functional definition. 

Well, we've certainly put certain items like this on the todo list before, and 
if you know of any that exist in the current code I don't think anyone would 
be against adding them to TODO (provided that there isn't a more immediate 
fix that would be implemented)

> Another example is "Allow commenting of variables 
> in postgresql.conf to restore them to defaults", which is beyound our
> expectation.
>

This doesn't seem like a good example, since this isn't an agreed upon desired 
behavior.  I mean some people agree with it but others don't so until we can 
decide on a plan of action it's hard to put specifics on the todo.  

> "Improvement" means something that we want to add does not exist before or
> usable but not that good. All the performance items and new functions
> should come here.
>
> However, there is blur border line between them and some "improvements"
> may have higher priority than "known issues". For example, those in the
> PITR section.
>

This is starting to sound like the "how do i determine the priority of xyz 
issues and/or set those priorities" idea. Typically these don't work well 
because any given issue is only as high priority as someone willing to fix 
it. 

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Why don't we allow DNS names in pg_hba.conf?
Next
From: Andrew Dunstan
Date:
Subject: Re: psql & readline & win32