Re: New developer papercut - Makefile references INSTALL - Mailing list pgsql-hackers

On Thu, Feb 10, 2022 at 12:52 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

(bringing this one back from the dead)



>
> Andres Freund <andres@anarazel.de> writes:
> > On 2022-02-09 22:32:59 +0100, Magnus Hagander wrote:
> >> post-commit hooks don't run on the git server, they run locally on
> >> your machine. There is a "post receive" hook that runs on the git
> >> server, but we definitely don't want that one to fabricate new commits
> >> I think.
>
> > Why not? We probably wouldn't want to do synchronously as part of the receive
> > hook, but if we have a policy that INSTALL is not to be updated by humans, but
> > updated automatically whenever its sources are modified, I'd be OK with
> > auto-committing that.

Auto committing in git becomes very.. Special. In that case you would
push but after that you would still not be in sync and have to pull
back down to compare.

It would also require the running of a comparatively very complex
build script inside the very restricted environment that is the git
master server. I do not want to have to deal with that level of
complexity there, and whatever security implications can come from it.

But if you want to accomplish something similar you could have a batch
job that runs on maybe a daily basis and builds the INSTALL file and
commits it to the repo. I still don't really like the idea of
committing automatically (in the github/gitlab world, having such a
tool generate a MR/PR would be perfectly fine, but pushing directly to
the repo I really prefer being something that has human eyes on the
process). Or post a patch with it for someone to look at.


> What happens when the INSTALL build fails (which is quite possible,
> I believe, even if a plain html build works)?

Yes, it breaks every time somebody accidentally puts a link to
somewhere else in the documentation, doesn't it?


> I don't really want any post-commit or post-receive hooks doing
> anything interesting to the tree.  I think the odds for trouble
> are significantly greater than any value we'd get out of it.

Very much agreed.


> I'm in favor of unifying README and README.git along the lines
> we discussed above.  I think that going further than that
> will be a lot of trouble for very little gain; in fact no gain,
> because I do not buy any of the arguments that have been
> made about why changing the INSTALL setup would be beneficial.
> If we adjust the README contents to be less confusing about that,
> we're done.

+1.

If anything, I'm more behind the idea of just getting rid of the
INSTALL file. A reference to the install instructions in the README
should be enough today. The likelihood of somebody getting a postgres
source tarball and trying to build it for the first time while not
having internet access is extremely low I'd say.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/