Обсуждение: Add a "Known Issues" section
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. AFAICS there are some long lasting problems there simply because hackers are not aware of or too trouble to fix. Splitting the TODO list will ring the bell more loudly. Regards, Qingqing
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.
regards, tom lane
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. Another example is "Allow commenting of variables in postgresql.conf to restore them to defaults", which is beyound our expectation. "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. Regards, Qingqing
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
Qingqing Zhou <zhouqq@cs.toronto.edu> writes:
> On Sun, 1 Jan 2006, Tom Lane wrote:
>> 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.
> ... However, there is blur border line between them ...
I don't think we want the top-level division of TODO to be a
classification that is inherently in-the-eye-of-the-beholder.
There would be way too much time wasted arguing what goes where,
to little purpose --- because, quite frankly, whether someone else
thinks XYZ is an issue has nothing to do with whether any given
developer is going to spend time on it tomorrow.
Things that are serious bugs (eg, server crashes) usually get fixed
fast enough that they never get on TODO in the first place. And many
of the things that might be called "known issues" don't belong on TODO
because we don't intend to change them (eg, identifier case folding
behavior).
It might be useful to pick up the "postgresql gotchas" list that's
out on the net someplace, and expand and maintain it as a resource
oriented mainly at new users: here are some things you might not have
expected to behave like that. I don't think this should have anything
directly to do with TODO though.
regards, tom lane
On Sun, Jan 01, 2006 at 08:37:02PM -0500, Tom Lane wrote: > Qingqing Zhou <zhouqq@cs.toronto.edu> writes: > > On Sun, 1 Jan 2006, Tom Lane wrote: > >> 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. > > > ... However, there is blur border line between them ... > > I don't think we want the top-level division of TODO to be a > classification that is inherently in-the-eye-of-the-beholder. > There would be way too much time wasted arguing what goes where, > to little purpose --- because, quite frankly, whether someone else > thinks XYZ is an issue has nothing to do with whether any given > developer is going to spend time on it tomorrow. A good test might be: would a release be held because of this item (assuming it was introduced by something in that release). BTW, a specific example that comes to mind is cluster disobeying MVCC. IIRC that results in data integrity issues, and I suspect that it would end up holding a release. ISTM this should be a high priority item because of the data integrity issue. > It might be useful to pick up the "postgresql gotchas" list that's > out on the net someplace, and expand and maintain it as a resource > oriented mainly at new users: here are some things you might not have > expected to behave like that. I don't think this should have anything > directly to do with TODO though. That is an interesting idea, though since the author of that list is already doing the work to maintain it, maybe we just point people there (which has the bonus of letting them see that there's a much larger MySQL gotchas list...) -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461