On Wed, Jul 30, 2014 at 9:16 AM, Gary Kotton <gkotton@vmware.com> wrote:
I am not really sure what to say on this one, but have a few comments in
1. At the moment in master we have to wait weeks and at times months to
get reviews on critical patches, yes, months and that is with begging
cores for reviews - so I am not sure how that will work.
2. The stable branch as of late seems to have been ignored by most stable
I am in favor of continuing the stable branch as it is now but I think
that we need to start to chase down the stable cores to do the work. If
they are not doing it then they should no longer be stable cores. It is
all about trust. I just think that if people are not reviewing - say at
least X reviews a month then they should be given a heads up that their
core status may be changed.
Maybe we need to redefine the goals of the project. I really do not think
that they should change.

On 7/30/14, 3:58 PM, "Thierry Carrez" <thierry@openstack.org> wrote:

>Hey folks,
>There is a thread on -dev about more generally relying on project core
>reviewers for stable branch maintenance:
>Let me know what you think about it, or better, chime in on that thread.
>I'm open to changing the current model. We could just do stable releases
>from time to time (warn about release, push tag, be done) and delegate
>maintenance of the branches themselves. That would certainly make our
>job easier. However I think the proponents for change (1) do not
>completely realize the difference in stable and master review, (2) do
>not represent all core reviewers and (3) don't realize how much extra
>work they are signing up for.
>Thierry Carrez (ttx)
>Openstack-stable-maint mailing list

Openstack-stable-maint mailing list

​Seems each project might have it's own challenges.  Personally for Cinder I'd really like to see us go back to each project and it's core team maintaining review and decision making ability.​  I do think that maintaining a synchronized schedule etc is still a requirement but I don't think anybody is suggesting we change that part.