I am making a quick change in how Keystone is handling updates to the sample 
config files until all of those discussion points are addressed in the big 
thread of “how do we handle sample configs".

These changes are just to help limit rebase issues and make contributions a bit 
easier to manage:

1. Please do not update the sample configuration in your main patch chain. 
Update the sample configuration outside (once your changes merge) or at the end 
of the chain.

2. I’ll start -1ing anything that is dependent on a sample.config change, this 
is so that we can avoid rebase nightmares because a lot of things touch the 
sample config.

3. I or one of the keystone core will be attempting to update the sample config 
on a regular basis to catch any updates that were otherwise missed.

4. Please do not add a -1 to a Keystone review for not updating the sample 
config. I’m asking the core team to ignore these -1s (only there because a 
sample config was not updated).

I hope this helps to keep code moving into the repository with fewer headaches. 
Once all the discussion around where sample config files go has been resolved 
(OpenStack wide) these policies are subject to change.

Cheers,
Morgan

-- 
Morgan Fainberg
__________________________________________________________________________
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

Reply via email to