I'm going to start out by making this clear: I am not looking to incite a flame war.

I've been working in Magnum for a couple of weeks now, and I'm starting to get down the processes for contribution. I'm here to talk about the process of always needing to have a patch associated with a bug or blueprint.

I have a good example of this being too strict. I knew the rules, so I opened [1] to say there are some improperly named variables and classes. I think it took longer for me to open the bug than it did to actually fix it. I think we need to start taking a look at how strict we need to be in requiring bugs to be opened and linked to patches. I understand it's a fine line between "it's broken" to "it would be nice to make this better".

I remember the debate when I was originally putting up [2] for review. The worry was that if these new tests would cut into developer productivity because it is more strict. The same argument can be applied to opening these bugs. If we have to open something up for everything we want to upload a patch for, that's just another step in the process to take up time.

Now, with my opinion out there, if we still want to take the direction of opening up bugs for everything, I will comply (I'm not the guy making decisions around here). I would like to see clear and present documentation explaining this to new contributors, though ([3] would probably be a good place to explain this).

Once again, not looking to start an argument. If everyone feels the way it works now is the best, I'm more than happy to join in :)

[1] https://bugs.launchpad.net/magnum/+bug/1496568
[2] https://review.openstack.org/#/c/217342/
[3] http://docs.openstack.org/developer/magnum/contributing.html

--
Thanks,

Ryan Rossiter (rlrossit)


__________________________________________________________________________
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

Reply via email to