Re: [openstack-dev] Spam of patches (was: [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?)
On 15:32 Jan 12, Julien Danjou wrote: > On Tue, Jan 12 2016, Amrith Kumar wrote: > > > My question to the ML is this, should stylistic changes of this kind be > > handled > > in a consistent way across all projects, maybe with a hacking rule and some > > discussion on the ML first? After all, if this change is worthwhile, it is > > worth ensuring that this construct that we are seeking to eliminate, does > > not > > reenter the code base. > > This is not stylistic, these are actual changes that can break the code > for no good reason. I've already -2'ed the Ceilometer one. > > Honestly, this kind of change are getting more and more a problem to us. > People invent a false bug, maybe report it to LP and mass-assign > projects, and then spam all the projects without any discussion before. > The worse thing is that most of these patches are wrong or incorrect, > add code-churn that just pollutes project history for no benefit. > > At the beginning, I had hope, and was being patient and tried to mentor > these new people with the hope that they'll learn and stick around. None > stayed. Is it just a "get me an free ATC pass" behavior, like someone > suggested? > > Now the spam amount is getting so high (several of these patches per > week these days) that I can't afford to be so patient and gentle > anymore, and I just -2 the patch with a brief explanation. I also have > to use the "mute bug mail" feature of Launchpad a lot, since I get > spammed by all the changes done the mass-assigned Launchpad bugs. > > So, how what can we do to fix that? It seems we're not communicating > proper behavior on how to jump into OpenStack to contribute and that > those "contributors" are not used to FOSS communities. FWIW Doug Hellmann mentioned this on the list later on [1]. If you find yourself going about making changes across multiple projects like this, you should start a discussion first. I think it'll be useful for this to be mentioned in the new contributors guide, after it's improved. I'll make a note about this now. [1] - http://lists.openstack.org/pipermail/openstack-dev/2016-January/084133.html -- Mike Perez __ 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
[openstack-dev] Spam of patches (was: [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?)
On Tue, Jan 12 2016, Amrith Kumar wrote: > My question to the ML is this, should stylistic changes of this kind be > handled > in a consistent way across all projects, maybe with a hacking rule and some > discussion on the ML first? After all, if this change is worthwhile, it is > worth ensuring that this construct that we are seeking to eliminate, does not > reenter the code base. This is not stylistic, these are actual changes that can break the code for no good reason. I've already -2'ed the Ceilometer one. Honestly, this kind of change are getting more and more a problem to us. People invent a false bug, maybe report it to LP and mass-assign projects, and then spam all the projects without any discussion before. The worse thing is that most of these patches are wrong or incorrect, add code-churn that just pollutes project history for no benefit. At the beginning, I had hope, and was being patient and tried to mentor these new people with the hope that they'll learn and stick around. None stayed. Is it just a "get me an free ATC pass" behavior, like someone suggested? Now the spam amount is getting so high (several of these patches per week these days) that I can't afford to be so patient and gentle anymore, and I just -2 the patch with a brief explanation. I also have to use the "mute bug mail" feature of Launchpad a lot, since I get spammed by all the changes done the mass-assigned Launchpad bugs. So, how what can we do to fix that? It seems we're not communicating proper behavior on how to jump into OpenStack to contribute and that those "contributors" are not used to FOSS communities. Cheers, -- Julien Danjou // Free Software hacker // https://julien.danjou.info signature.asc Description: PGP signature __ 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
Re: [openstack-dev] Spam of patches
On 01/12/2016 09:32 AM, Julien Danjou wrote: > On Tue, Jan 12 2016, Amrith Kumar wrote: > >> My question to the ML is this, should stylistic changes of this kind be >> handled >> in a consistent way across all projects, maybe with a hacking rule and some >> discussion on the ML first? After all, if this change is worthwhile, it is >> worth ensuring that this construct that we are seeking to eliminate, does not >> reenter the code base. > > This is not stylistic, these are actual changes that can break the code > for no good reason. I've already -2'ed the Ceilometer one. > > Honestly, this kind of change are getting more and more a problem to us. > People invent a false bug, maybe report it to LP and mass-assign > projects, and then spam all the projects without any discussion before. > The worse thing is that most of these patches are wrong or incorrect, > add code-churn that just pollutes project history for no benefit. > For anyone interested here, this is the most recent example of this that I've seen (and not the first time this same faulty change has been discussed in Cinder): https://bugs.launchpad.net/cinder/+bug/1512207 The change suggested here makes unit tests weaker, but many projects have already landed this change. I'd just like to be another voice to say: these changes are often not as simple as they look, and really need careful review. __ 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
Re: [openstack-dev] Spam of patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/12/2016 09:32 AM, Julien Danjou wrote: > On Tue, Jan 12 2016, Amrith Kumar wrote: > >> My question to the ML is this, should stylistic changes of this >> kind be handled in a consistent way across all projects, maybe >> with a hacking rule and some discussion on the ML first? After >> all, if this change is worthwhile, it is worth ensuring that this >> construct that we are seeking to eliminate, does not reenter the >> code base. > > This is not stylistic, these are actual changes that can break the > code for no good reason. I've already -2'ed the Ceilometer one. > > Honestly, this kind of change are getting more and more a problem > to us. People invent a false bug, maybe report it to LP and > mass-assign projects, and then spam all the projects without any > discussion before. The worse thing is that most of these patches > are wrong or incorrect, add code-churn that just pollutes project > history for no benefit. > > At the beginning, I had hope, and was being patient and tried to > mentor these new people with the hope that they'll learn and stick > around. None stayed. Is it just a "get me an free ATC pass" > behavior, like someone suggested? > > Now the spam amount is getting so high (several of these patches > per week these days) that I can't afford to be so patient and > gentle anymore, and I just -2 the patch with a brief explanation. I > also have to use the "mute bug mail" feature of Launchpad a lot, > since I get spammed by all the changes done the mass-assigned > Launchpad bugs. > > So, how what can we do to fix that? It seems we're not > communicating proper behavior on how to jump into OpenStack to > contribute and that those "contributors" are not used to FOSS > communities. I think Julien raises a very important point here. This kind of contribution and the way it is communicated is sub optimal for the effective operation of our developer's workflow. I too have tried to mentor many new folks hoping they would learn open source workflows and even though some of them understood and implemented (one or two even payed it forward) most of them have moved o n. This kind of behaviour puts a lot of load on developers and each person addresses it in their own way. One of the things I see is a fragmentation of what I had believed to be camaraderie as everyone is forced to come up with their own individual solution to deal with this demand. I don't have a solution but I agree with Julien that it is a problem. Thanks Julien, Anita. > > Cheers, > > > > __ > > 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 > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWlRSwAAoJELmKyZugNFU02QQIAK/kojQBGbfqtoqMTdlmhg+b ah/Sz5761Z8xL6p7DSsJPPJQN3WpwxkJt06pzGog1QfGNDb5nRGLeqBk2YxkEqFm eqH5vraDDqzkijo3kg1kLd4e8N3BkfxWNzGnlnbppp8o6T2bh7qWuXzlkDiTF9Zh iL+6jvBmmoFkc5nXEeACLcEsQ7gw4Sz/pEv+1Y9UX6XJGlsy75eRMwLxGNU7T5Cp 2fMIzOH2+mpMApmjyZYU65BNqj/WralweUrBhMkMBIss8381kH1AtqvzSei32Lvb lOX6Rh6Wq7cD5+aacg4HbxbXcMnudAK47N7ZBoDtF7au+UBzI8oC+RKpNiXE2OI= =Mdxr -END PGP SIGNATURE- __ 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
