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
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? |