On 09/12/2017 11:30 AM, Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>> Tom Lane wrote:
>>> Aleksander Alekseev <a.alekseev@postgrespro.ru> writes:
>>>> === Apply Failed: 29 ===
>>>> https://commitfest.postgresql.org/14/1235/ (Support arrays over domain types)
>>> Can you clarify what went wrong for you on that one? I went to rebase it,
>>> but I end up with the identical patch except for a few line-numbering
>>> variations.
>> I think "git apply" refuses to apply a patch if it doesn't apply
>> exactly. So you could use "git apply -3" (which merges) or just plain
>> old "patch" and the patch would work fine.
>> If the criteria is that strict, I think we should relax it a bit to
>> avoid punting patches for pointless reasons. IOW I think we should at
>> least try "git apply -3".
> FWIW, I always initially apply patches with good ol' patch(1). So for
> me, whether that way works would be the most interesting thing. Don't
> know about other committers' workflows.
Yeah, that's what I do, too.
>
>> Also, at this point this should surely be just an experiment.
> +1 ... seems like there's enough noise here that changing patch status
> based on the results might be premature. Still, I applaud the effort.
I think a regular report of what doesn't apply and what doesn't build
will be very useful on its own, especially if there are links to the
failure reports. When we are satisfied that we're not getting
significant numbers of false negatives over a significant period we can
talk about automating CF state changes. I agree this is nice work.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers