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

Re: Add a "Known Issues" section

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Add a "Known Issues" section
Date: 2006-01-01 23:50:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sunday 01 January 2006 17:30, Qingqing Zhou wrote:
> On Sun, 1 Jan 2006, Tom Lane wrote:
> > Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)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 

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

In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2006-01-01 23:51:37
Subject: Re: psql & readline & win32
Previous:From: Andrew DunstanDate: 2006-01-01 23:37:22
Subject: Re: Why don't we allow DNS names in pg_hba.conf?

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