Open Stack

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 <sean at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev