Open Stack

On Fri, Sep 22, 2017 at 1:25 AM, Chris Smart <mail at csmart.io> wrote:
> On Fri, 22 Sep 2017, at 12:21, Matt Riedemann wrote:
>> I just wanted to highlight to people that there seems to be a series of
>> garbage patches in various projects [1] which are basically doing things
>> like fixing a single typo in a code comment, or very narrowly changing
>> http to https in links within docs.
>>
>> Also +1ing ones own changes.
>>
>> I've been trying to snuff these out in nova, but I see it's basically a
>> pattern widespread across several projects.
>>
>
> For what it's worth, I agree. A few days ago I gave a -1 and commented
> on around 50 patches which were adding --- to the top of generally two
> yaml files: one was a template the other was a test.
>
> Another patchset removed a single space from the end of a line of a
> comment.
>
> After my comments they ware all abandoned.
>
> Given the waste of resources, I can't help but wonder if we should be
> re-visiting the way initial check gate is kicked off?

Yes!!! if the cleanup patches that address comment typos, whitespace
linting and other small changes like this are considered contribution padding
then can we filter for them and reduce load and contribution padding that
everyone is so concerned about but still allow some of these general entry
level commits to get through and into the code bases?  If it's detectable to be
comment/whitespace only change CI job for that review can be a much
reduced as it does not impact CI.  If it is documentation only changes,
it could be limited to linting and docs building/verification jobs but
not run the
heavier Functional/integration CI jobs that may waste resources.

> Should someone else have to do an initial +1? (Acknowledging that this
> could be a colleague and other offender.)
>
> Or could the gate be smarter about the types of changes (like checking
> for one liners or changes to comments, etc)?
>
> Or at least there should be a way for anyone to kill a review if it is
> clearly a waste of resources?

This should be taken into consideration with how to accept contributions from
new developers or people interested in the code base.  I will acknowledge that
there may be some incentives to getting patch landed.  If it's easy enough to
negate the Load on CI system of these patches, and reduced incentive for this
type of patch then the number of these types of patches that are submitted just
for contribution padding will decrease and it will make the projects a bit more
open to new interested contributors.  If you make the hurdle to get a small
change that makes the code harder to read/understand a possible new contributor
may just decide to abandon the change and walk away from the project.

> Or detect patch bombing across projects.


-- 
Jon Schlueter
jschluet at redhat.com
IRC: jschlueter/yazug