If this is the bug that triggered this discussion, yes, please never do anything like that - https://bugs.launchpad.net/python-openstacksdk/+bug/1475722
The bug now has too many projects to take any actions on it. I think a basic rule of thumb that before creating a bug that has > 4 projects on it, make sure that you've socialized that idea on the mailing list. Work that actually cuts across that many projects really is going to need a community discussion to figure out where it phases things in. On 09/21/2016 08:15 AM, gordon chung wrote: > i feel like this gets brought up every year. we block these patches in > Telemetry projects unless they can be justified beyond the copy/paste > description. > > in addition to this, please, PLEASE stop creating 'all project bugs'. i > don't want to get emails on updates to projects unrelated to the ones i > care about. also, it makes updating the bug impossible because it times > out. i'm too lazy to search ML but this has been raise before, please stop. > > let's all unite together and block these patches to bring an end to it. :) > > On 21/09/16 07:56 AM, Amrith Kumar wrote: >> Of late I've been seeing a lot of rather questionable changes that >> appear to be getting blasted out across multiple projects; changes that >> cause considerable code churn, and don't (IMHO) materially improve the >> quality of OpenStack. >> >> I’d love to provide a list of the changes that triggered this email but >> I know that this will result in a rat hole where we end up discussing >> the merits of the individual items on the list and lose sight of the >> bigger picture. That won’t help address the question I have below in any >> way, so I’m at a disadvantage of having to describe my issue in abstract >> terms. >> >> >> >> Here’s how I characterize these changes (changes that meet one or more >> of these criteria): >> >> >> >> - Contains little of no information in the commit message (often just >> a single line) >> >> - Makes some generic statement like “Do X not Y”, “Don’t use Z”, >> “Make ABC better” with no further supporting information >> >> - Fail (literally) every single CI job, clearly never tested by the >> developer >> >> - Gets blasted across many projects, literally tens with often the >> same kind of questionable (often wrong) change >> >> - Makes a stylistic python improvement that is not enforced by any >> check (causes a cottage industry of changes making the same correction >> every couple of months) >> >> - Reverses some previous python stylistic improvement with no clear >> reason (another cottage industry) >> >> >> >> I’ve tried to explain it to myself as enthusiasm, and a desire to >> contribute aggressively; I’ve lapsed into cynicism at times and tried to >> explain it as gaming the numbers system, but all that is merely >> rationalization and doesn’t help. >> >> >> >> Over time, the result generally is that these developers’ changes get >> ignored. And that’s not a good thing for the community as a whole. We >> want to be a welcoming community and one which values all contributions >> so I’m looking for some suggestions and guidance on how one can work >> with contributors to try and improve the quality of these changes, and >> help the contributor feel that their changes are valued by the project? >> Other more experienced PTL’s, ex-PTL’s, long time open-source-community >> folks, I’m seriously looking for suggestions and ideas. >> >> >> >> Any and all input is welcome, do other projects see this, how do you >> handle it, is this normal, … >> >> >> >> Thanks! >> >> >> >> -amrith >> > > cheers, > -- Sean Dague http://dague.net __________________________________________________________________________ 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
