Christian Convey <christian.con...@gmail.com> writes:
>> well I personally think the level to meet would be that all the systems
>> on the buildfarm that can build -HEAD at the time the patch is proposed
>> for a commit should be able to build using the new system with whatever
>> cmake version is available in those by default (if it is at all).
> I see. In other projects I've worked on, the configuration of a build
> farm has been driven by some list of platforms that were considered
> important to support.
> Is that the case here as well? I.e., is the build-farm population
> just a convenient proxy for some other source of information regarding
> what platforms are important?
To a large extent, the buildfarm population is interesting because those
machines represent platforms for which someone is willing to put their
money where their mouth is, ie go to the effort of maintaining a buildfarm
member. For those cases, we're likely to hear complaints if we break it.
There are also buildfarm members that are really only there as coal mine
canaries, that is, we don't want to break compatibility by accident ---
but if there were a good reason for it, we might be willing to throw those
platforms overboard. My HPPA/HPUX dinosaur is certainly in that category,
for example.
I do not think we have a project policy about where the dividing line
is, though.
BTW, Stefan's formulation supposes that on platforms where the vendor
didn't supply any version of cmake, we can tell people to install whatever
version we want. But that's assuming something not in evidence, namely
that cmake works on those platforms at all, in any version. We'll have
a lot of legwork to do to find out what platforms we are risking losing.
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
