Re: branching for 9.2devel

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: branching for 9.2devel
Дата
Msg-id BANLkTin1ifhLn+aE2wWLKUWHN7ezJf6KCQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: branching for 9.2devel  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: branching for 9.2devel  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: branching for 9.2devel  (Christopher Browne <cbbrowne@gmail.com>)
Re: branching for 9.2devel  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Mon, Apr 25, 2011 at 3:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> One small issue that would have to be resolved before branching is
> whether and when to do a "final" pgindent run for 9.1.  Seems like the
> alternatives would be:
>

If the tools become easy to run is it possible we cold get to the
point where we do an indent run on every commit? This wold require a
stable list of system symbols plus the tool would need to add any new
symbols added by the patch. As long as the tool produced consistent
output I don't see that it would produce the spurious merge conflicts
we've been afraid of in the past. Those would only occur if a patch
went in without pgindent being run, someone developed a patch against
that tree, then pgindent was run before merging that patch. As long as
it's run on every patch on commit it shouldn't cause those problems
since nobody could use a non-pgindented code as their base.

Personally I've never really liked the pgindent run. White-space
always seemed like the least interesting of the code style issues,
none of which seemed terribly important compared to the more important
things like staying warning-clean and defensive coding rules. But if
we're going to do it letting things diverge for a whole release and
then running it once a year seems the worst of both worlds.

--
greg


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: intermittent FD regression check failure
Следующее
От: Robert Haas
Дата:
Сообщение: Re: make check in contrib