Re: branching for 9.2devel

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: branching for 9.2devel
Date: 2011-04-25 18:43:22
Message-ID: BANLkTi=ErBbt5ijBNuYuoXgxCfwDrgr+0Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 25, 2011 at 4:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> No, not at all, because you're ignoring the common case of a series of
> dependent patches that are submitted in advance of the first one having
> been committed.

Uh, true.

> To get to the point where we could do things that way, it would have
> to be the case that every developer could run pgindent locally and get
> the same results that the committer would get.  Maybe we'll get there
> someday, and we should certainly try.  But we're not nearly close enough
> to be considering changing policy on that basis.

Fwiw I tried getting Gnu indent to work. I'm having a devil of a time
figuring out how to get even remotely similar output.

I can't even get -ncsb to work which means it puts *every* one-line
comment into a block with the /* and */ delimiters on a line by
themselves. And it does line-wrapping differently such that any lines
longer than the limit are split at the *first* convenient place rather
than the last which produces some, imho, strange looking lines.

And it doesn't take a file for the list of typedefs. You have to
provide each one as an argment on the command-line. I hacked the
source to add the typedefs to the gperf hash it uses but if we have to
patch it it rather defeats the point of even pondering switching.

Afaict it hasn't seen development since 2008 so I don't get the
impression it's any more of a live project than the NetBSD source.

All in all even if they've fixed the things it used to mangle I don't
see much point in switching from one moribund project we have to patch
to another moribund project we have to patch, especially as it will
mean patches won't backpatch as easily since the output will be quite
different.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2011-04-25 18:50:28 Re: Unfriendly handling of pg_hba SSL options with SSL off
Previous Message Alvaro Herrera 2011-04-25 18:39:17 Re: offline consistency check and info on attributes