Stephen Frost <sfr...@snowman.net> writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Yes, moving the goalposts on ease-of-use is an important consideration >> here. What that says to me is that we ought to pull FreeBSD indent >> into our tree, and provide Makefile support that makes it easy for >> any developer to build it and put it into their PATH. (I suppose >> that means support in the MSVC scripts too, but somebody else will >> have to do that part.)
> I'm not a huge fan of this, however. Do we really need to carry around > the FreeBSD indent in our tree? I had been expecting that these changes > would eventually result in a package that's available in the common > distributions (possibly from apt/yum.postgresql.org, at least until it's > in the main Debian-based and RHEL-based package systems). Are you > thinking that we'll always have to have our own modified version? I certainly would rather that our version matched something that's under active maintenance someplace. But it seems like there are two good arguments for having a copy in our tree: * easy accessibility for PG developers * at any given time we need to be using a specific "blessed" version, so that all developers can get equivalent results. There's pretty much no chance of that happening if we depend on distro-provided packages, even if those share a common upstream. We've had reasonably decent luck with tracking the tzcode/tzdata packages as local copies, so I feel like we're not taking on anything unreasonable if our model is that we'll occasionally (not oftener than once per year) update our copy to recent upstream and then re-indent using that. > What about perltidy itself..? We don't include that in our tree either. Not being much of a Perl guy, I don't care one way or the other about perltidy. Somebody else can work on that if it needs work. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers