Re: No Issue Tracker - Say it Ain't So!

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: No Issue Tracker - Say it Ain't So!
Дата
Msg-id 10183.1443198771@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: No Issue Tracker - Say it Ain't So!  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: No Issue Tracker - Say it Ain't So!  (Joe Conway <mail@joeconway.com>)
Re: No Issue Tracker - Say it Ain't So!  (Simon Riggs <simon@2ndQuadrant.com>)
Re: No Issue Tracker - Say it Ain't So!  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> I have frequently been the agent of change in matters of process, but I see
> no useful change here, just lots of wasted time. But then why are we even
> talking about change? What thing is broken that needs to be fixed? Why is
> adopting a new package a fix for that?

Fair questions indeed.  I think the core points here are:

1. We don't have a good process for making sure things don't "slip through
the cracks".  I think everyone more or less relies on Bruce to run through
his mailbox periodically and nag them about threads that don't seem to
have been closed off.  The deficiencies of that are obvious.

2. There's no visibility for outsiders as to what issues are open or
recently fixed.  Not being outsiders, I'm not sure that we are terribly
well qualified to describe this problem precisely or identify a good
solution --- but I grant that there's a problem there.

I do not know how much emphasis the project should place on point #2.
By definition, fixing that will not return any direct benefit to us.
However, point #1 is clearly an issue and I think a low-overhead fix
for it would be a good thing.  If we can get some answer for #2 out
of it at the same time, even better.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Fix an O(N^2) problem in foreign key references.
Следующее
От: Nikolay Shaplov
Дата:
Сообщение: Re: pageinspect patch, for showing tuple data