From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: branches_of_interest.txt |
Date: | 2018-07-02 08:39:57 |
Message-ID: | 7cd8fe24-4e08-8b40-d9d0-a7f091763466@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.)
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Sergei Kornilov | 2018-07-02 08:42:17 | Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query |
Previous Message | Daniel Gustafsson | 2018-07-02 08:38:36 | Re: CREATE TABLE .. LIKE .. EXCLUDING documentation |