Re: [git-for-windows] Re: Continuous Testing of Git on Windows

From: Philip Oakley <philipoakley@iee.org>
Date: Feb 18, 2017, 11:49 UTC
Message-ID: <D4A69FDAB8BD4D0080108611B61E5EF8@PhilipOakley>
In-Reply-To: <xmqq60kb0ywi.fsf@gitster.mtv.corp.google.com>

From: "Junio C Hamano" <gitster@pobox.com>
Sent: Thursday, February 16, 2017 12:20 AM

Show 10 quoted lines

> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> It may even be worth 'splitting' the pu branch sequence into the
>> existing pu (with merges from series that are selected as reasonable),
>> and then a pr branch (public review?) on top of that holding the rest
>> of the series that have been submitted, so that the CI can do a full
>> test on the tips of them to support those devs with limited test
>> capability.
>
> I won't stop you from publishing such a pr branch yourself.

But would others see it?... (rhetorical, better thoughts below))

Show 5 quoted lines

>
> For patches whose merit is not clear because the problem they try to
> solve is under-explained, whose solution is ill-designed, etc., IOW,
> with issues that makes me judge that they are not interesting enough
> for 'pu',

It is reasonble that that a project's integrator is able to make these decisions. For some projects they may have a layered approach of descisions which does allow the gradations for the submitted feature series.

Some of this does fall into dscho's differentiation between those patch series that should pass the CI (continuous integration) testing, and those that are there for CT (continuous testing) feedback. This could either be an extra branch marking the transition, or a named commit similar to the "pu^{/^### match next}", etc. In some ways it is similar to my 'pr' suggestion, without the inclusion of the 'all and sundry' series.

For for integrators who are willing/want to recieve any/all contributions for public view (usually those for projects of a more lenient and less critical variety), then even the CT grouping could then have those additional pr submissions. For Git, you provide that that 'voice of reason' for gatekeeping the pu branch.

Show 5 quoted lines

> it is not worth my time to deal with whitespace brekages
> in them to make them not even apply, to figure out what base the
> patches are meant to apply to, or to resolve conflicts caused by
> them with topics already in flight, etc.
>

If a centralised CT service was available to the project, maybe via the GitHub PR process (which isn't curently used by the project) then is may be a way of allowing the 'all and sundry' contributors to get their ideas upto a basic level before even bothering yourself (because PRs do not trouble you).

It may need an extra gatekeeper between the passing patches (PRs) and auto submission (the Heroku script thingy) which could flood the list with with inane changes - one only has to look at the http://stackoverflow.com/questions/tagged/git stream to see that.

At least if there was a break point within pu that allowed differentiation between the series that should fit a CI view, and those that are still at the CT stage, then that may help.

Thanks

Philip.