Re: a raft of parallelism-related bug fixes

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Peter Geoghegan <pg(at)heroku(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: a raft of parallelism-related bug fixes
Date: 2016-02-17 22:17:29
Message-ID: 56C4F179.7090700@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/8/16 4:39 PM, Peter Geoghegan wrote:
> On Mon, Feb 8, 2016 at 2:35 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> I think having a public git tree, that contains the current state, is
>> greatly helpful for that. Just announce that you're going to screw
>> wildly with history, and that you're not going to be terribly careful
>> about commit messages. That means observers can just do a fetch and a
>> reset --hard to see the absolutely latest and greatest. By all means
>> post a series to the list every now and then, but I think for minor
>> changes it's perfectly sane to say 'pull to see the fixups for the
>> issues you noticed'.
>
> I would really like for there to be a way to do that more often. It
> would be a significant time saver, because it removes problems with
> minor bitrot.

Yeah, I think it's rather silly that we limit ourselves to only pushing
patches through a mailing list. That's OK (maybe even better) for simple
stuff, but once there's more than 1 patch it's a PITA.

There's an official github mirror of the code, ISTM it'd be good for
major features to get posted to github forks in their own branches. I
think that would also make it easy for buildfarm owners to run tests
against trusted forks/branches.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2016-02-17 22:17:47 Re: exposing pg_controldata and pg_config as functions
Previous Message Tom Lane 2016-02-17 22:14:31 Re: exposing pg_controldata and pg_config as functions