On Fri, Sep 22, 2017 at 1:25 AM, Chris Smart <m...@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 jschl...@redhat.com IRC: jschlueter/yazug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev