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: 200601011850.59230.xzilla@users.sourceforge.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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
it.

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

In response to

Browse pgsql-hackers by date

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