So it turns out that trove just has this rule disabled. At least I now know more about how this stuff works, I guess. Sorry for the confusion.
Greg On Jan 7, 2014, at 9:54 AM, Sean Dague <s...@dague.net> wrote: > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev