From: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql: Introduce timeout handling framework |
Date: | 2012-07-17 15:08:36 |
Message-ID: | CAEYLb_XxZFm+P0UAvq6oEoJkUguh3isNSUDjQ_Y2-xTP=pQn9Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On 17 July 2012 14:43, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> This seems to have broken Windows builds. (And if people need reminding,
> cross-compiling is pretty easy:
> <http://people.planetpostgresql.org/andrew/index.php?/archives/264-Cross-compiling-PostgreSQL-for-WIndows.html>
> )
Perhaps I'm asking a naive question, but wouldn't it be easier if
people had the opportunity to use the buildfarm without actually
committing something? For example, perhaps the buildfarm could be made
to run on a staging branch. Commits would actually be made to the
staging branch. If and when the regression tests pass, the
infrastructure then pushes the staging branch commit onto the master
branch, and the commit is really committed - the -commiters list is
now informed of this. If there is a problem with the buildfarm, the
committer receives an e-mail informing them of this. The commit is
non-destructively reverted on the staging branch.
I don't know that it's worth worrying about, nor if the turnaround on
having a commit not break the buildfarm would be generally acceptable
in this situation. It would be nice to keep commit history cleaner,
though.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2012-07-17 15:49:42 | Re: pgsql: Introduce timeout handling framework |
Previous Message | Tom Lane | 2012-07-17 14:14:28 | pgsql: Put back storage/proc.h in postmaster.c. |