Re: [openstack-dev] [All][Neutron] Improving development and review velocity - Is it time for a drastic change?

2016-04-01 Thread Victor Stinner 

Le 01/04/2016 03:12, Assaf Muller a écrit :

2) Now, transform yourself six to twelve months in the future. We now
face a new problem. (...) I hereby propose that we remove the
tests. (...) Needless to say, my
proposal keeps pep8 in place. We all know how important a consistent
style is.


The good news is that it fits well with the next Python version, Python 
8, which will run pep8 checks for you when you import a module!

https://mail.python.org/pipermail/python-dev/2016-March/143603.html

It makes pep8 jobs useless.

Victor

__
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

Re: [openstack-dev] [All][Neutron] Improving development and review velocity - Is it time for a drastic change?

2016-04-01 Thread Neil Jerram 
On 01/04/16 02:16, Assaf Muller wrote:
> Have you been negatively impacted by slow development and review
> velocity? Read on.
>
> OpenStack has had a slow review velocity for as long as I can
> remember. This has a cascading effect where people take up multiple
> tasks, so that they can work on something while the other is being
> reviewed. This adds even more patches to ever growing queues. Features
> miss releases and bugs never get fixed. Even worse, we turn away new
> contributors due to an agonizing process.
>
> In the Neutron community, we've tried a few things over the years.
> Neutron's growing scope was identified and load balancing, VPN and
> firewall as a service were split out to their own repositories.
> Neutron core reviewers had less load, *aaS contributors could iterate
> faster, it was a win win. Following that, Neutron plugins were split
> off as well. Neutron core reviewers did not have the expertise or
> access to specialized hardware of vendors anyway, vendors could
> iterate faster, and everybody were happy. Finally, a specialization
> system was created. Areas of the Neutron code base were determined and
> a "Lieutenant" was chosen for each area. That lieutenant could then
> nominate core reviewers, and those reviewers were then expected to +2
> only within their area. This led to doubling the core team, and for my
> money was a great success. Leading us to today.
>
> Today, I think it's clear we still have a grave problem. Patches sit
> idle for months, turning contributors away. I believe we've reached a
> tipping point, and now is the time for out of the box thinking. I am
> proposing two changes:
>
> 1) Changing what a core reviewer is. It is time to move to a system of
> trust: Everyone have +2 rights to begin with, and the system
> self-regulates by shaming offending individuals and eventually taking
> away rights for repeated errors in judgement. I've proposed a Neutron
> governance change here:
>
> https://review.openstack.org/300271
>
> 2) Now, transform yourself six to twelve months in the future. We now
> face a new problem. Patches are flying in. You're no longer working on
> a dozen patches in parallel. You push up something, it is reviewed
> promptly, and you move on to the next thing. Our next issue is then CI
> run-time. The time it takes to test (Check queue), approve and test a
> patch again (Gate queue) is simply too long. How do we cut this down?
> Again, by using a proven open source methodology of trust. As
> Neutron's testing lieutenant, I hereby propose that we remove the
> tests.

You had me until this sentence. :-)  Nice one!

Neil

> Why deal with a problem you can avoid in the first place? The
> Neutron team has been putting out fires in the form of gate issues on
> a weekly basis, double so late in to a release cycle. The gate has so
> many false negatives, the tests are riddled with race conditions,
> we've clearly failed to get testing right. Needless to say, my
> proposal keeps pep8 in place. We all know how important a consistent
> style is. I've proposed a patch that removes Neutron's tests here:
>
> https://review.openstack.org/300272
>
> __
> 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
>


__
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

Re: [openstack-dev] [All][Neutron] Improving development and review velocity - Is it time for a drastic change?

2016-04-01 Thread Ihar Hrachyshka 

Shinobu Kinjo  wrote:


https://review.openstack.org/300271


This change would make sense. But will we have core reviewers election?


Obviously no, since you won’t have a ‘core reviewer’ term now. But what we  
really want is having a separate offensive name for those whole +2 rights  
were revoked. I already made several suggestions in the patch, like  
‘neutron-wreckless-core’ or ‘neutron-chaos-maint’.


As for elections, we should definitely have some public shaming process  
where those who still maintain +2 rights could -2 offenders. We could even  
have it as part of our social event on each summit. Nothing like a good ol'  
witch hunting.


Ihar

__
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

Re: [openstack-dev] [All][Neutron] Improving development and review velocity - Is it time for a drastic change?

2016-03-31 Thread Nikhil Komawar 
And now I wish I could delete my messages sent to ML.

On 3/31/16 9:38 PM, Nikhil Komawar wrote:
> 2) is a giveaway it's Apr 1 (in some TZs)!
>
>
> On 3/31/16 9:12 PM, Assaf Muller wrote:
>> Have you been negatively impacted by slow development and review
>> velocity? Read on.
>>
>> OpenStack has had a slow review velocity for as long as I can
>> remember. This has a cascading effect where people take up multiple
>> tasks, so that they can work on something while the other is being
>> reviewed. This adds even more patches to ever growing queues. Features
>> miss releases and bugs never get fixed. Even worse, we turn away new
>> contributors due to an agonizing process.
>>
>> In the Neutron community, we've tried a few things over the years.
>> Neutron's growing scope was identified and load balancing, VPN and
>> firewall as a service were split out to their own repositories.
>> Neutron core reviewers had less load, *aaS contributors could iterate
>> faster, it was a win win. Following that, Neutron plugins were split
>> off as well. Neutron core reviewers did not have the expertise or
>> access to specialized hardware of vendors anyway, vendors could
>> iterate faster, and everybody were happy. Finally, a specialization
>> system was created. Areas of the Neutron code base were determined and
>> a "Lieutenant" was chosen for each area. That lieutenant could then
>> nominate core reviewers, and those reviewers were then expected to +2
>> only within their area. This led to doubling the core team, and for my
>> money was a great success. Leading us to today.
>>
>> Today, I think it's clear we still have a grave problem. Patches sit
>> idle for months, turning contributors away. I believe we've reached a
>> tipping point, and now is the time for out of the box thinking. I am
>> proposing two changes:
>>
>> 1) Changing what a core reviewer is. It is time to move to a system of
>> trust: Everyone have +2 rights to begin with, and the system
>> self-regulates by shaming offending individuals and eventually taking
>> away rights for repeated errors in judgement. I've proposed a Neutron
>> governance change here:
>>
>> https://review.openstack.org/300271
>>
>> 2) Now, transform yourself six to twelve months in the future. We now
>> face a new problem. Patches are flying in. You're no longer working on
>> a dozen patches in parallel. You push up something, it is reviewed
>> promptly, and you move on to the next thing. Our next issue is then CI
>> run-time. The time it takes to test (Check queue), approve and test a
>> patch again (Gate queue) is simply too long. How do we cut this down?
>> Again, by using a proven open source methodology of trust. As
>> Neutron's testing lieutenant, I hereby propose that we remove the
>> tests. Why deal with a problem you can avoid in the first place? The
>> Neutron team has been putting out fires in the form of gate issues on
>> a weekly basis, double so late in to a release cycle. The gate has so
>> many false negatives, the tests are riddled with race conditions,
>> we've clearly failed to get testing right. Needless to say, my
>> proposal keeps pep8 in place. We all know how important a consistent
>> style is. I've proposed a patch that removes Neutron's tests here:
>>
>> https://review.openstack.org/300272
> Well played! But 2) gave it away =]
>
>> __
>> 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

-- 

Thanks,
Nikhil


__
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

Re: [openstack-dev] [All][Neutron] Improving development and review velocity - Is it time for a drastic change?

2016-03-31 Thread Shinobu Kinjo 
On Fri, Apr 1, 2016 at 10:12 AM, Assaf Muller  wrote:
> Have you been negatively impacted by slow development and review
> velocity? Read on.
>
> OpenStack has had a slow review velocity for as long as I can
> remember. This has a cascading effect where people take up multiple
> tasks, so that they can work on something while the other is being
> reviewed. This adds even more patches to ever growing queues. Features
> miss releases and bugs never get fixed. Even worse, we turn away new
> contributors due to an agonizing process.
>
> In the Neutron community, we've tried a few things over the years.
> Neutron's growing scope was identified and load balancing, VPN and
> firewall as a service were split out to their own repositories.
> Neutron core reviewers had less load, *aaS contributors could iterate
> faster, it was a win win. Following that, Neutron plugins were split
> off as well. Neutron core reviewers did not have the expertise or
> access to specialized hardware of vendors anyway, vendors could
> iterate faster, and everybody were happy. Finally, a specialization
> system was created. Areas of the Neutron code base were determined and
> a "Lieutenant" was chosen for each area. That lieutenant could then
> nominate core reviewers, and those reviewers were then expected to +2
> only within their area. This led to doubling the core team, and for my
> money was a great success. Leading us to today.
>
> Today, I think it's clear we still have a grave problem. Patches sit
> idle for months, turning contributors away. I believe we've reached a
> tipping point, and now is the time for out of the box thinking. I am
> proposing two changes:
>
> 1) Changing what a core reviewer is. It is time to move to a system of
> trust: Everyone have +2 rights to begin with, and the system
> self-regulates by shaming offending individuals and eventually taking
> away rights for repeated errors in judgement. I've proposed a Neutron
> governance change here:
>
> https://review.openstack.org/300271

This change would make sense. But will we have core reviewers election?

>
> 2) Now, transform yourself six to twelve months in the future. We now
> face a new problem. Patches are flying in. You're no longer working on
> a dozen patches in parallel. You push up something, it is reviewed
> promptly, and you move on to the next thing. Our next issue is then CI
> run-time. The time it takes to test (Check queue), approve and test a
> patch again (Gate queue) is simply too long. How do we cut this down?
> Again, by using a proven open source methodology of trust. As
> Neutron's testing lieutenant, I hereby propose that we remove the
> tests. Why deal with a problem you can avoid in the first place? The
> Neutron team has been putting out fires in the form of gate issues on
> a weekly basis, double so late in to a release cycle. The gate has so
> many false negatives, the tests are riddled with race conditions,
> we've clearly failed to get testing right. Needless to say, my
> proposal keeps pep8 in place. We all know how important a consistent
> style is. I've proposed a patch that removes Neutron's tests here:
>
> https://review.openstack.org/300272
>
> __
> 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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

Re: [openstack-dev] [All][Neutron] Improving development and review velocity - Is it time for a drastic change?

2016-03-31 Thread Nikhil Komawar 
2) is a giveaway it's Apr 1 (in some TZs)!


On 3/31/16 9:12 PM, Assaf Muller wrote:
> Have you been negatively impacted by slow development and review
> velocity? Read on.
>
> OpenStack has had a slow review velocity for as long as I can
> remember. This has a cascading effect where people take up multiple
> tasks, so that they can work on something while the other is being
> reviewed. This adds even more patches to ever growing queues. Features
> miss releases and bugs never get fixed. Even worse, we turn away new
> contributors due to an agonizing process.
>
> In the Neutron community, we've tried a few things over the years.
> Neutron's growing scope was identified and load balancing, VPN and
> firewall as a service were split out to their own repositories.
> Neutron core reviewers had less load, *aaS contributors could iterate
> faster, it was a win win. Following that, Neutron plugins were split
> off as well. Neutron core reviewers did not have the expertise or
> access to specialized hardware of vendors anyway, vendors could
> iterate faster, and everybody were happy. Finally, a specialization
> system was created. Areas of the Neutron code base were determined and
> a "Lieutenant" was chosen for each area. That lieutenant could then
> nominate core reviewers, and those reviewers were then expected to +2
> only within their area. This led to doubling the core team, and for my
> money was a great success. Leading us to today.
>
> Today, I think it's clear we still have a grave problem. Patches sit
> idle for months, turning contributors away. I believe we've reached a
> tipping point, and now is the time for out of the box thinking. I am
> proposing two changes:
>
> 1) Changing what a core reviewer is. It is time to move to a system of
> trust: Everyone have +2 rights to begin with, and the system
> self-regulates by shaming offending individuals and eventually taking
> away rights for repeated errors in judgement. I've proposed a Neutron
> governance change here:
>
> https://review.openstack.org/300271
>
> 2) Now, transform yourself six to twelve months in the future. We now
> face a new problem. Patches are flying in. You're no longer working on
> a dozen patches in parallel. You push up something, it is reviewed
> promptly, and you move on to the next thing. Our next issue is then CI
> run-time. The time it takes to test (Check queue), approve and test a
> patch again (Gate queue) is simply too long. How do we cut this down?
> Again, by using a proven open source methodology of trust. As
> Neutron's testing lieutenant, I hereby propose that we remove the
> tests. Why deal with a problem you can avoid in the first place? The
> Neutron team has been putting out fires in the form of gate issues on
> a weekly basis, double so late in to a release cycle. The gate has so
> many false negatives, the tests are riddled with race conditions,
> we've clearly failed to get testing right. Needless to say, my
> proposal keeps pep8 in place. We all know how important a consistent
> style is. I've proposed a patch that removes Neutron's tests here:
>
> https://review.openstack.org/300272

Well played! But 2) gave it away =]

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

-- 

Thanks,
Nikhil



__
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

[openstack-dev] [All][Neutron] Improving development and review velocity - Is it time for a drastic change?

2016-03-31 Thread Assaf Muller 
Have you been negatively impacted by slow development and review
velocity? Read on.

OpenStack has had a slow review velocity for as long as I can
remember. This has a cascading effect where people take up multiple
tasks, so that they can work on something while the other is being
reviewed. This adds even more patches to ever growing queues. Features
miss releases and bugs never get fixed. Even worse, we turn away new
contributors due to an agonizing process.

In the Neutron community, we've tried a few things over the years.
Neutron's growing scope was identified and load balancing, VPN and
firewall as a service were split out to their own repositories.
Neutron core reviewers had less load, *aaS contributors could iterate
faster, it was a win win. Following that, Neutron plugins were split
off as well. Neutron core reviewers did not have the expertise or
access to specialized hardware of vendors anyway, vendors could
iterate faster, and everybody were happy. Finally, a specialization
system was created. Areas of the Neutron code base were determined and
a "Lieutenant" was chosen for each area. That lieutenant could then
nominate core reviewers, and those reviewers were then expected to +2
only within their area. This led to doubling the core team, and for my
money was a great success. Leading us to today.

Today, I think it's clear we still have a grave problem. Patches sit
idle for months, turning contributors away. I believe we've reached a
tipping point, and now is the time for out of the box thinking. I am
proposing two changes:

1) Changing what a core reviewer is. It is time to move to a system of
trust: Everyone have +2 rights to begin with, and the system
self-regulates by shaming offending individuals and eventually taking
away rights for repeated errors in judgement. I've proposed a Neutron
governance change here:

https://review.openstack.org/300271

2) Now, transform yourself six to twelve months in the future. We now
face a new problem. Patches are flying in. You're no longer working on
a dozen patches in parallel. You push up something, it is reviewed
promptly, and you move on to the next thing. Our next issue is then CI
run-time. The time it takes to test (Check queue), approve and test a
patch again (Gate queue) is simply too long. How do we cut this down?
Again, by using a proven open source methodology of trust. As
Neutron's testing lieutenant, I hereby propose that we remove the
tests. Why deal with a problem you can avoid in the first place? The
Neutron team has been putting out fires in the form of gate issues on
a weekly basis, double so late in to a release cycle. The gate has so
many false negatives, the tests are riddled with race conditions,
we've clearly failed to get testing right. Needless to say, my
proposal keeps pep8 in place. We all know how important a consistent
style is. I've proposed a patch that removes Neutron's tests here:

https://review.openstack.org/300272

__
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