Re: branches_of_interest.txt

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: branches_of_interest.txt
Date: 2018-07-02 15:37:25
Message-ID: 63839.1530545845@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-07-01 11:41:07 -0400, Tom Lane wrote:
>> I can see the value of people other than you being able to change it,
>> but keeping it in the core repo seems like a kluge not a proper solution.

> FWIW, I've a manually maintained version of this in the scripts I use to
> commit / backpatch things. I'd appreciate not having to manually
> maintain it, and be afraid to forget updating it ;)

Yeah, I have something similar as well, in fact a couple of them.
I thought about whether I'd change those scripts to use an in-tree
branches_of_interest list, and I concluded that most likely I would
not, because the instant at which I decide a given branch is no longer
interesting to me is not necessarily the same instant at which we
shut down the buildfarm support for it. It has even less to do with
the time that I next do a "git pull" after that shutdown. Contrariwise,
once a new branch has been created in the repo, I need to set up a workdir
for it before it can safely be added to the list of branches I auto
push/pull. So giving up control of the timing just isn't gonna work well.

If we were to keep this info in a separate repo requiring a separate
"git pull", it might be manageable since I could control when I update
that. But then you're right back to the situation of requiring a manual
step you might forget.

In any case, if we do put this into the tree, I want it to be named
and treated as something that *only* controls the buildfarm, not any
other stuff. We'll regret tying other stuff to that.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Arseny Sher 2018-07-02 15:52:09 Re: pgsql: Fix "base" snapshot handling in logical decoding
Previous Message Tom Lane 2018-07-02 15:22:25 Re: Should contrib modules install .h files?