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.

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?

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.

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 :)

If we could have one member from networking-ovn on the neutron-stable-maint team that would be great. That means the member would have to be trusted not to handle neutron-patches when not knowing what he's doing, and of course, follow the stable guidelines, which are absolutely important. But I believe everybody takes the role seriously.

If that's not a reasonable solution, then I'd vote for the specific stable maintainers instead. But we need something to help us handle issues quicker and at

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.

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 :)

>> 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.

>> 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.

> 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.

>
>>> 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: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On Wed, Dec 20, 2017 at 7:18 PM, Lucas Alvares Gomes
<[hidden email]> 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.

>
>>> 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: OpenStack-dev-request@...?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

If we could have one member from networking-ovn on the neutron-stable-maint team that would be great. That means the member would have to be trusted not to handle neutron-patches when not knowing what he's doing, and of course, follow the stable guidelines, which are absolutely important. But I believe everybody takes the role seriously.

It'll still take two +2 to push a patch in, and the oversight from more seasoned stable reviewers is still there to assist more inexperienced ones. Aside from the occasional lag, I don't believe that backports linger as much as they used to, but with the help of the dashboard and the initiative of the individual project maintainers velocity should increase. To be honest, I am not sure why we didn't do that before, similar review rights apply to things like specs reviews and neutron-lib changes. As for your concern about people stepping out of their own turf, I honestly don't believe that's a problem in reality, and even if it was, I always encourage people to reach out on IRC or other means.

I don't have admin rights to the neutron-stable-maint team, fo that someone has to nudge Ihar :)

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.

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 :)

Please tell me who from the OVN group is ready to take the burden, and
I will make you part of neutron-stable-maint. I think it's ok to be
more laissez faire with backports for subprojects than we were used
to, with the recent drop in core team membership and reduced capacity.

>
>
> On 20 December 2017 at 00:27, Miguel Angel Ajo Pelayo <[hidden email]>
> wrote:
>>
>> If we could have one member from networking-ovn on the
>> neutron-stable-maint team that would be great. That means the member would
>> have to be trusted not to handle neutron-patches when not knowing what he's
>> doing, and of course, follow the stable guidelines, which are absolutely
>> important. But I believe everybody takes the role seriously.
>
>
> It'll still take two +2 to push a patch in, and the oversight from more
> seasoned stable reviewers is still there to assist more inexperienced ones.
> Aside from the occasional lag, I don't believe that backports linger as much
> as they used to, but with the help of the dashboard and the initiative of
> the individual project maintainers velocity should increase. To be honest, I
> am not sure why we didn't do that before, similar review rights apply to
> things like specs reviews and neutron-lib changes. As for your concern about
> people stepping out of their own turf, I honestly don't believe that's a
> problem in reality, and even if it was, I always encourage people to reach
> out on IRC or other means.
>
> I don't have admin rights to the neutron-stable-maint team, fo that someone
> has to nudge Ihar :)
>
> HTH
> Armando
>
> [1] https://docs.openstack.org/project-team-guide/stable-branches.html>
>>
>>
>> If that's not a reasonable solution, then I'd vote for the specific stable
>> maintainers instead. But we need something to help us handle issues quicker
>> and at
>> the same time, in a controlled manner.
>>
>> Best,
>> Miguel Ángel.
>>
>> On Tue, Dec 19, 2017 at 5:48 PM Armando M. <[hidden email]> wrote:
>>>
>>> On 19 December 2017 at 08:21, Lucas Alvares Gomes <[hidden email]>
>>> wrote:
>>>>
>>>> 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>>>
>>>>
>>>> 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 :)
>>>
>>> HTH
>>> Armando
>>>
>>>>
>>>> [0] https://review.openstack.org/#/c/523623/>>>>
>>>> Cheers,
>>>> Lucas
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> [hidden email]?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> [hidden email]?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: [hidden email]?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>

> Please tell me who from the OVN group is ready to take the burden, and
> I will make you part of neutron-stable-maint. I think it's ok to be
> more laissez faire with backports for subprojects than we were used
> to, with the recent drop in core team membership and reduced capacity.

Great! I will reach out the OVN core team so we make a decision about
who should do it.

For the record, I added Lucas to the gerrit group. I assume he will
mostly focus on OVN patches. You are still welcome to review other
repo patches, and if you stick to it, I am happy to expand your role
to cover all of them.

As for OVN, you only have one +2, and existing stable reviewers may
not be responsive. Don't hesitate to poke us about patches that block
your progress or don't attract enough attention in let's say a week.

> Hi,
>
>> Please tell me who from the OVN group is ready to take the burden, and
>> I will make you part of neutron-stable-maint. I think it's ok to be
>> more laissez faire with backports for subprojects than we were used
>> to, with the recent drop in core team membership and reduced capacity.
>
> Great! I will reach out the OVN core team so we make a decision about
> who should do it.
>
> Cheers,
> Lucas
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev