On 01/07/2014 10:19 AM, Greg Hill wrote:
> Thanks Sean. I'll work on adding this one to the hacking repo. That brings
> up another question, though, what are the implications of suddenly enforcing
> a rule that wasn't previously enforced? I know there are at least 30 other
> violations of this rule just within trove, and I imagine larger projects
> probably have more. I'd hate to be the target of all the ire that sudden
> rejections of every commit would cause. Do we have a way to make it off by
> default for some period to let the projects all clean themselves up then turn
> it on by default after that?
New rules only get released as part of new semver bumps on hacking, and
all the projects are pinned on their upper bound on hacking. i.e.
hacking>=0.8.0,<0.9
So new rules would be going into the 0.9.x release stream at this point.
Once 0.9.0 is released, we'll up the global requirements. Then projects
should update their pins, and either address the issues, or add an
ignore for the rules they do not want to enforce (either by policy, or
because now is not a good time to fix them).
So it is minimally disruptive.
-Sean
--
Sean Dague
http://dague.net
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
