[openstack-dev] coding standards question
greg.hill at RACKSPACE.COM
Tue Jan 7 16:15:20 UTC 2014
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.
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.
> 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 Dague
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev