Re: branches_of_interest.txt

On Mon, Jul 2, 2018 at 4:45 AM, Magnus Hagander <magnus@hagander.net> wrote:
>
>
> On Mon, Jul 2, 2018 at 10:39 AM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>>
>> On 01.07.18 17:41, 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.
>> > In particular, once it'd been around for awhile so that the master copy
>> > had diverged from the back branches' copies, that would be pretty
>> > confusing IMO.
>>
>> Yeah, I'd find this kind of weird.  The version control system contains
>> the code, not the other way around.
>>
>> > Is it worth the trouble of having a separate repo for info that
>> > shouldn't
>> > be tied to a particular PG development branch?  I'm not quite sure what
>> > else we would keep there besides this file, but perhaps other use-cases
>> > will come up.  Some of the stuff in src/tools/ has a bit of this flavor.
>>
>> The web site has some information about which versions are current, so
>> maybe there is an opportunity to hook the buildfarm in there.
>>
>> (I also have to change some things on babel.postgresql.org every time a
>> branch is made.)
>
>
> We could definitely do that on the website, if people think that's the
> easiest.
>
> We could also set up a separate git repository with exactly the same set of
> committers as the main one (but only use the master branch there) as one
> option. The maintenance cost of doing so would be very close to zero as we
> have all the infrastructure for it already. so it'd be more about which one
> is more convenient to use.
>


Ideally this would be done as part of creating the new branch. Since
the web site doesn't have the same set of committers, a second metdata
repo like this seems sensible.
An alternative would be to create a special branch within the core
repo for such data, something like this (The first two lines are the
ones that are most important):

    git checkout --orphan metadata
    git rm --cached -r .
    wget https://buildfarm.postgresql.org/branches_of_interest.txt
    git add branches_of_interest.txt
    git commit -m 'initial content' branches_of_interest.txt
    git push origin HEAD
    git checkout master

The new branch won't share any history or files with the existing branches.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services