Обсуждение: [HACKERS] Re-indent HEAD tomorrow?
Barring objections, I'd like to reindent HEAD with the new version
of pg_bsd_indent (and correspondingly updated pgindent script)
tomorrow, say around 1800 UTC.
regards, tom lane
I wrote:
> Barring objections, I'd like to reindent HEAD with the new version
> of pg_bsd_indent (and correspondingly updated pgindent script)
> tomorrow, say around 1800 UTC.
... and it's done.
regards, tom lane
On Wed, Jun 21, 2017 at 04:07:30PM -0400, Tom Lane wrote: > I wrote: > > Barring objections, I'd like to reindent HEAD with the new version > > of pg_bsd_indent (and correspondingly updated pgindent script) > > tomorrow, say around 1800 UTC. > > ... and it's done. You are eventually doing all active branches, right? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bruce Momjian <bruce@momjian.us> writes:
> On Wed, Jun 21, 2017 at 04:07:30PM -0400, Tom Lane wrote:
>> ... and it's done.
> You are eventually doing all active branches, right?
I don't think we'd entirely decided that we should do that, or when
to do it. I'm not in a huge hurry; we might find some more tweaks
we want to make -- particularly around typedef collection -- before
we call it done.
For reference, the patchset wound up changing just about 10000 lines,
out of a total code base approaching 1.4M lines, so less than 1%
churn. That's not as bad as I'd thought it would be going in.
But I'm not sure if that represents an argument for or against
reindenting the back branches. It's probably more than the number of
lines affected by that 8.1 comment-right-margin adjustment that caused
us so much back-patching pain later.
Right now we're really just speculating about how much pain there will
be, on either end of this. So it'd be interesting for somebody who's
carrying large out-of-tree patches (EDB? Citus?) to try the new
pgindent version on a back branch and see how much of their patches no
longer apply afterwards. And I think it'd make sense to wait a few
months and garner some experience with back-patching from v10 into the
older branches, so we have more than guesses about how much pain not
reindenting will be for us.
I'd earlier suggested that waiting till around the time of 10.0
release might be a good idea, and that still seems like a
reasonable timeframe.
regards, tom lane
On 2017-06-21 17:28:32 -0400, Tom Lane wrote: > Right now we're really just speculating about how much pain there will > be, on either end of this. So it'd be interesting for somebody who's > carrying large out-of-tree patches (EDB? Citus?) to try the new > pgindent version on a back branch and see how much of their patches no > longer apply afterwards. Citus isn't a patched version of postgres anymore, butan extension (with some ugly hacks to make that possible ...). Therefore it shouldn't affect us in any meaningful way. > And I think it'd make sense to wait a few > months and garner some experience with back-patching from v10 into the > older branches, so we have more than guesses about how much pain not > reindenting will be for us. Hm. A few days / a week or two, okay. But a few months? That'll incur the backpatch cost during all that time... Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes:
> On 2017-06-21 17:28:32 -0400, Tom Lane wrote:
>> And I think it'd make sense to wait a few
>> months and garner some experience with back-patching from v10 into the
>> older branches, so we have more than guesses about how much pain not
>> reindenting will be for us.
> Hm. A few days / a week or two, okay. But a few months? That'll incur
> the backpatch cost during all that time...
We can always move up the decision date if we find that our pain
sensors have overloaded.
regards, tom lane
On Wed, Jun 21, 2017 at 5:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Right now we're really just speculating about how much pain there will > be, on either end of this. So it'd be interesting for somebody who's > carrying large out-of-tree patches (EDB? Citus?) to try the new > pgindent version on a back branch and see how much of their patches no > longer apply afterwards. EDB is not continuously reapplying patches; we have branches into which the upstream reindents would have to be merged. As a broad statement, reindenting all of the back branches is surely going to create some extra work for whoever has to do those merges, but if that's what the community thinks is best, we will of course manage. It's not *that* bad. It would be slightly less annoying for us, I think, if the reindent were done immediately after a minor-release rather than at some other random point in time. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Jun 22, 2017 at 10:38:41AM -0400, Robert Haas wrote: > On Wed, Jun 21, 2017 at 5:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Right now we're really just speculating about how much pain there will > > be, on either end of this. So it'd be interesting for somebody who's > > carrying large out-of-tree patches (EDB? Citus?) to try the new > > pgindent version on a back branch and see how much of their patches no > > longer apply afterwards. > > EDB is not continuously reapplying patches; we have branches into > which the upstream reindents would have to be merged. As a broad > statement, reindenting all of the back branches is surely going to > create some extra work for whoever has to do those merges, but if > that's what the community thinks is best, we will of course manage. > It's not *that* bad. > > It would be slightly less annoying for us, I think, if the reindent > were done immediately after a minor-release rather than at some other > random point in time. Also keep in mind that if we don't reindent all active branches then even forks of Postgres will have merge conflicts in backporting of their own patches, meaning the community and forks will have backbranch patch difficulties. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +