Re: Patch queue -> wiki

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Patch queue -> wiki
Дата
Msg-id 27542.1207363037@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Patch queue -> wiki  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Patch queue -> wiki  (Bruce Momjian <bruce@momjian.us>)
Re: Patch queue -> wiki  ("Joshua D. Drake" <jd@commandprompt.com>)
Список pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> I think ultimately we are going to have to remove the patches email list
> and require patch submitters to add their patches to a patch tracker. 

That's outright silly.  The email list and archives are a critical part
of what we do, because they provide a historical record.  Nor is raising
the bar for submitting patches a good idea.

The patch queue is by definition transient --- nobody particularly cares
about what its past state was, as shown by the fact that you've gotten
along for years with an implementation that's incapable of recalling
past state.  (Now I do like the idea that a wiki-based patch queue would
retain some history, but I'm not expecting that it'll archive every
change indefinitely.)

The right way to think about and design the patch queue is as a changing
index into the archives.  One of the things I seriously dislike about
your current implementation is that it ignores the archives.  You've
whacked us around two or three times this month developing "permanent"
and then "really permanent" URLs, but that whole thing is wrong from the
get-go.  You are not the keeper of the project's historical record.
The patch queue should be trafficking in URLs that do point into the
historical record.

> Frankly, few people seem to want to apply patches either.  :-)

Yeah, tell me about it :-(
        regards, tom lane


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

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: Patch queue -> wiki
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Implement current_query(), that shows the currently executing