Re: Add a "Known Issues" section

Поиск
Список
Период
Сортировка
От Robert Treat
Тема Re: Add a "Known Issues" section
Дата
Msg-id 200601011850.59230.xzilla@users.sourceforge.net
обсуждение исходный текст
Ответ на Re: Add a "Known Issues" section  (Qingqing Zhou <zhouqq@cs.toronto.edu>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Why don't we allow DNS names in pg_hba.conf?
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: psql & readline & win32