Re: Patches that don't apply or don't compile: 2017-09-12

At Wed, 13 Sep 2017 08:13:08 +0900, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote in <CAB7nPqTx=xq9XMqCgf9XEmq_PVEW99n6wjWDHi8aR3nnExyfGQ(at)mail(dot)gmail(dot)com>
> On Wed, Sep 13, 2017 at 7:39 AM, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> >> On 12 Sep 2017, at 23:54, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> >> With all due respect, it's hard not to see this as a disruption of the
> >> current CF. I agree automating the patch processing is a worthwhile
> >> goal, but we're not there yet and it seems somewhat premature.
> >>
> >> Let me explain why I think so:
> >>
> >> (1) You just changed the status of 10-15% open patches. I'd expect
> >> things like this to be consulted with the CF manager, yet I don't see
> >> any comments from Daniel. Considering he's been at the Oslo PUG meetup
> >> today, I doubt he was watching hackers very closely.
> >
> > Correct, I’ve been travelling and running a meetup today so had missed this on
> > -hackers.
>
> FWIW, I tend to think that the status of a patch ought to be changed
> by either a direct lookup at the patch itself or the author depending
> on how the discussion goes on, not an automatic processing. Or at
> least have more delay to allow people to object as some patches can be
> applied, but do not apply automatically because of naming issues.
> There are as well people sending test patches to allow Postgres to
> fail on purpose, for example see the replication slot issue not able
> to retain a past segment because the beginning of a record was not
> tracked correctly on the receiver-side. This can make the recovery
> tests fail, but we want them to fail to reproduce easily the wanted
> failure.

Agreed. I'd like to have a means to exclude a part of patches
from the CI check. As another issue I can guess is that we
sometimes fix the commit on which a patch(set) applies for a
while especially for big patches, which gets many stubs
continuously by new commits.

> >> (2) You gave everyone about 4 hours to object, ending 3PM UTC, which
> >> excludes about one whole hemisphere where it's either too early or too
> >> late for people to respond. I'd say waiting for >24 hours would be more
> >> appropriate.
> >
> > Agreed.
>
> Definitely. Any batch updates have to involve the CFM authorization at
> least, in this case Daniel.

+9(JST)

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center