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
