Re: Preliminary results for proposed new pgindent implementation
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Robert Haas <robertmhaas@gmail.com>,
Stephen Frost <sfrost@snowman.net>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Piotr Stefaniak <postgres@piotr-stefaniak.me>
Date: 2017-06-16T18:23:00Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2017-06-16 13:34:01 -0400, Tom Lane wrote: >> I do intend to apply the diffs to HEAD in multiple steps, just to >> make them more reviewable. But I think we should probably absorb >> all the changes we want into v10, not leave some for later cycles. > Btw, how much are you planning to backpatch these? Well, that's something we need to discuss. I originally argued for back-patching the new rules, whatever they are (ie, run the new pgindent on the back branches whenever we've agreed that the dust has settled). But I'm starting to realize that that's likely to be horrid for anyone who's carrying out-of-tree patches, as I know a lot of packagers do for instance. We have to trade off our own inconvenience in making back-patches against inconvenience to people who are maintaining private patchsets. One idea that occurs to me after a few minutes' thought is to announce that we will reindent the back branches, but not till around the time of v10 final release. Once v10 is out, anybody who's carrying a private patchset will be needing to think about rebasing it on top of reindented code anyway, so dealing with that in the back branches at the same time might be a bit less work. Or we could leave the back branches alone and anticipate five years worth of pain in back-patching. I don't find that very appetizing personally, but it might be the easiest sell to the majority of the community, since very few of us do back-patching work on a regular basis. regards, tom lane
Commits
-
Manually un-break a few URLs that pgindent used to insist on splitting.
- 780b3a4c43fd 10.0 landed
-
Remove entab and associated detritus.
- 81f056c7256f 10.0 landed
-
Phase 3 of pgindent updates.
- 382ceffdf7f6 10.0 landed
-
Phase 2 of pgindent updates.
- c7b8998ebbf3 10.0 landed
-
Initial pgindent run with pg_bsd_indent version 2.0.
- e3860ffa4dd0 10.0 landed
-
Adjust pgindent script to use pg_bsd_indent 2.0.
- 8ff6d4ec7840 10.0 landed
-
Final pgindent run with old pg_bsd_indent (version 1.3).
- 9ef2dbefc7fb 10.0 landed