From: "Junio C Hamano" <gitster@xxxxxxxxx>
Sent: Thursday, February 16, 2017 12:20 AM
"Philip Oakley" <philipoakley@xxxxxxx> 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))
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.
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.