That may help, of course, but I gues it could also be capacity related. On Wed, Dec 20, 2017 at 11:42 AM Takashi Yamamoto <[email protected]> wrote:
> On Wed, Dec 20, 2017 at 7:18 PM, Lucas Alvares Gomes > <[email protected]> wrote: > > Hi, > > > >>> Hi all, > >>> > >>> Just sending this email to try to understand the model for stable > branch maintenance in networking-ovn (potentially other neutron drivers > too). > >>> > >>> Right now, only members of the ``neutron-stable-maint`` gerrit group > are able to approve patches for the stable branches; this can cause some > delays when fixing things (e.g [0]) because we don't have any member in > that group that is also a ``networking-ovn-core`` member. So, sometimes we > have to go around and ping people to take a look at the patches and it > kinda sucks. > >> > >> > >> We had a Gerrit dashboard that helped stable reviewers stay on top of > things [1], but it looks like it doesn't seem to work anymore. My > suggestion would be to look into that as the lack of visibility might be > the source of the recent delay. > >> > >> [1] > https://docs.openstack.org/neutron/latest/contributor/dashboards/index.html#gerrit-dashboards > > > > ++ indeed, lack of visibility is a problem as well. > > and lack of visibility of the fix of the dashboard? :-) > https://review.openstack.org/#/c/479138/ > > > > >>> Is there any reason why things are set up in that way ? > >>> > >>> I was wondering if it would make sense to create a new group to help > maintaining the stable branches in networking-ovn. The new group could > include some of the core members willing to do the work + > ``neutron-stable-maint`` as a subgroup. Is that reasonable, what you think > about it? > >> > >> > >> Rather than create yet another group(s), it makes sense to have an > individual from each neutron project participate in the > neutron-stable-maint team (whose admin rights I think are held by Ihar as > neutron member), for those of whom have actually an interest in reviewing > stable patches :) > >> > > > > Having a member in the current group will help, if you are comfortable > > with adding a new member to the current group that would be great. > > > > The reason why I was leaning towards having another group is because > > of scope limitation. Members of the ``neutron-stable-maint`` group can > > approve patches for all neutron-related projects stable branches. By > > having a separated group, members would only be able to approve things > > for a specific project. > > > > The new group would also have the ``neutron-stable-maint`` as a > > sub-group to it , so the members of the original group would still > > able approve things everywhere. > > > > Anyway, either ideas would help with the original problem, I'm good > > with whatever approach people thinks is best. > > > > Cheers, > > Lucas > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
