settingsLogin | Registersettings

[openstack-dev] [Fuel] Abandon changesets which hang for a while without updates

0 votes

Hi,
we have too many patches which hang for over a month without attention.
Almost all are those which should be abandoned due to changes happened in
master, and need complete rework. Or, those were just proposals to make
something, which didn't fly. Unfortunately there are those which were good
ideas, but didn't attract enough attention from cores and didn't land into
master as a result.

Anyway, I think we need to keep our review queues in better health. Can we
enable auto-abandon back again, if patch is hanging out for a month or more?
--
Mike Scherbakov

mihgen


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jul 7, 2015 in openstack-dev by Mike_Scherbakov (9,460 points)   1 4 6

15 Responses

0 votes

Folks,
let's execute here. Numbers are still large. Did we have a chance to look
over the whole queue?

Can we go ahead and abandon changes having -1 or -2 from reviewers for over
than a months or so?
I'm all for just following standard OpenStack process [1], and then change
it only if there is good reason for it.

[1] https://wiki.openstack.org/wiki/Puppet#Patch_abandonment_policy

On Thu, Jul 9, 2015 at 6:27 PM Stanislaw Bogatkin sbogatkin@mirantis.com
wrote:

2 weeks seems too small for me. We easy can be in situation when fix for
medium bug is done, but SCF starts. And gap between SCF and release easily
can be more than a month. So, 2 months seems okay for me if speaking about
forcibly applying auto-abandon by major vote. And I'm personally against
such innovation at all.

On Thu, Jul 9, 2015 at 5:37 PM, Davanum Srinivas davanum@gmail.com
wrote:

That's a very good plan ("Initial feedback/triage") Mike.

thanks,
dims

On Thu, Jul 9, 2015 at 3:23 PM, Mike Scherbakov
mscherbakov@mirantis.com wrote:

+1 for just reusing existing script, and adjust it on the way. No need
to
immediately switch from infinite time to a couple of weeks, we can
always
adjust it later. But 1-2 month should be a good start already.

Our current stats [1] look just terrible. Before we enable an
auto-abandon,
we need to go every single patch first, and review it / provide comment
to
authors. The idea is not to abandon some good patches, and not to offend
contributors...

Let's think how we can approach it. Should we have core reviewers to
check
their corresponding components?

[1] http://stackalytics.com/report/reviews/fuel-group/open

On Wed, Jul 8, 2015 at 1:13 PM Sean M. Collins sean@coreitpro.com
wrote:

Let's keep it at >4 weeks without comment, and Jenkins failed - similar
to the script that Kyle Mestery uses for Neutron. In fact, we could
actually just use his script ;)

https://github.com/openstack/neutron/blob/master/tools/abandon_old_reviews.sh

--
Sean M. Collins


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Mike Scherbakov

mihgen


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Davanum Srinivas :: https://twitter.com/dims


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Mike Scherbakov

mihgen


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 16, 2015 by Mike_Scherbakov (9,460 points)   1 4 6
0 votes

I'm with Stanislaw on this one: abandoning reviews just to make numbers
look better will accomplish nothing.

The only benefit I can see is cleaning up reviews that we know don't need
to be considered, so that it's easier for reviewers to find the reviews
that still need attention. I don't see this as that much of a problem,
finding stuff to review in Fuel Review Inbox [0] is not hard at all.

[0] https://wiki.openstack.org/wiki/Fuel#Development_related_links

And the state of our review backlog is such that it's not safe to
auto-abandon reviews without looking at them, and if a contributor has
spent time looking at a review, abandoning it manually is one click away.

If we do go with setting up an auto-abandon rule, it should be extremely
conservative, for example: CR has a negative vote from a core reviewer AND
there were no comments or positive votes from anyone after that AND it has
not been touched in any way for 2 months.

On Wed, Jul 15, 2015 at 5:10 PM Mike Scherbakov mscherbakov@mirantis.com
wrote:

Folks,
let's execute here. Numbers are still large. Did we have a chance to look
over the whole queue?

Can we go ahead and abandon changes having -1 or -2 from reviewers for
over than a months or so?
I'm all for just following standard OpenStack process [1], and then change
it only if there is good reason for it.

[1] https://wiki.openstack.org/wiki/Puppet#Patch_abandonment_policy

On Thu, Jul 9, 2015 at 6:27 PM Stanislaw Bogatkin sbogatkin@mirantis.com
wrote:

2 weeks seems too small for me. We easy can be in situation when fix for
medium bug is done, but SCF starts. And gap between SCF and release easily
can be more than a month. So, 2 months seems okay for me if speaking about
forcibly applying auto-abandon by major vote. And I'm personally against
such innovation at all.

On Thu, Jul 9, 2015 at 5:37 PM, Davanum Srinivas davanum@gmail.com
wrote:

That's a very good plan ("Initial feedback/triage") Mike.

thanks,
dims

On Thu, Jul 9, 2015 at 3:23 PM, Mike Scherbakov
mscherbakov@mirantis.com wrote:

+1 for just reusing existing script, and adjust it on the way. No need
to
immediately switch from infinite time to a couple of weeks, we can
always
adjust it later. But 1-2 month should be a good start already.

Our current stats [1] look just terrible. Before we enable an
auto-abandon,
we need to go every single patch first, and review it / provide
comment to
authors. The idea is not to abandon some good patches, and not to
offend
contributors...

Let's think how we can approach it. Should we have core reviewers to
check
their corresponding components?

[1] http://stackalytics.com/report/reviews/fuel-group/open

On Wed, Jul 8, 2015 at 1:13 PM Sean M. Collins sean@coreitpro.com
wrote:

Let's keep it at >4 weeks without comment, and Jenkins failed -
similar
to the script that Kyle Mestery uses for Neutron. In fact, we could
actually just use his script ;)

https://github.com/openstack/neutron/blob/master/tools/abandon_old_reviews.sh

--
Sean M. Collins


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Mike Scherbakov

mihgen


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Davanum Srinivas :: https://twitter.com/dims


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Mike Scherbakov

mihgen


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 17, 2015 by Dmitry_Borodaenko (7,240 points)   1 3 5
0 votes

Just adding an experience from another project, Neutron.

We had similar debates, and prepping for the long apocalyptic winter of changeset death, Kyle decimated the world and ran the abandon script. The debates were far more intense than the reality, and my large stockpile of Rad-X and Nuka Cola went to waste.

Every few weeks, I get a few emails of things being abandoned. And if I care about something, mine or not, I click through and tap ‘Restore’. If one person in the entire community can’t be bothered to click one button, I’m not sure how it’d ever be kept up-to-date, much less merge.

Thanks,
doug

On Jul 16, 2015, at 8:36 PM, Dmitry Borodaenko dborodaenko@mirantis.com wrote:

I'm with Stanislaw on this one: abandoning reviews just to make numbers look better will accomplish nothing.

The only benefit I can see is cleaning up reviews that we know don't need to be considered, so that it's easier for reviewers to find the reviews that still need attention. I don't see this as that much of a problem, finding stuff to review in Fuel Review Inbox [0] is not hard at all.

[0] https://wiki.openstack.org/wiki/Fuel#Development_related_links https://wiki.openstack.org/wiki/Fuel#Development_related_links

And the state of our review backlog is such that it's not safe to auto-abandon reviews without looking at them, and if a contributor has spent time looking at a review, abandoning it manually is one click away.

If we do go with setting up an auto-abandon rule, it should be extremely conservative, for example: CR has a negative vote from a core reviewer AND there were no comments or positive votes from anyone after that AND it has not been touched in any way for 2 months.

On Wed, Jul 15, 2015 at 5:10 PM Mike Scherbakov <mscherbakov@mirantis.com mscherbakov@mirantis.com> wrote:
Folks,
let's execute here. Numbers are still large. Did we have a chance to look over the whole queue?

Can we go ahead and abandon changes having -1 or -2 from reviewers for over than a months or so?
I'm all for just following standard OpenStack process [1], and then change it only if there is good reason for it.

[1] https://wiki.openstack.org/wiki/Puppet#Patch_abandonment_policy https://wiki.openstack.org/wiki/Puppet#Patch_abandonment_policy

On Thu, Jul 9, 2015 at 6:27 PM Stanislaw Bogatkin <sbogatkin@mirantis.com sbogatkin@mirantis.com> wrote:
2 weeks seems too small for me. We easy can be in situation when fix for medium bug is done, but SCF starts. And gap between SCF and release easily can be more than a month. So, 2 months seems okay for me if speaking about forcibly applying auto-abandon by major vote. And I'm personally against such innovation at all.

On Thu, Jul 9, 2015 at 5:37 PM, Davanum Srinivas <davanum@gmail.com davanum@gmail.com> wrote:
That's a very good plan ("Initial feedback/triage") Mike.

thanks,
dims

On Thu, Jul 9, 2015 at 3:23 PM, Mike Scherbakov
<mscherbakov@mirantis.com mscherbakov@mirantis.com> wrote:

+1 for just reusing existing script, and adjust it on the way. No need to
immediately switch from infinite time to a couple of weeks, we can always
adjust it later. But 1-2 month should be a good start already.

Our current stats [1] look just terrible. Before we enable an auto-abandon,
we need to go every single patch first, and review it / provide comment to
authors. The idea is not to abandon some good patches, and not to offend
contributors...

Let's think how we can approach it. Should we have core reviewers to check
their corresponding components?

[1] http://stackalytics.com/report/reviews/fuel-group/open

On Wed, Jul 8, 2015 at 1:13 PM Sean M. Collins <sean@coreitpro.com sean@coreitpro.com> wrote:

Let's keep it at >4 weeks without comment, and Jenkins failed - similar
to the script that Kyle Mestery uses for Neutron. In fact, we could
actually just use his script ;)

https://github.com/openstack/neutron/blob/master/tools/abandon_old_reviews.sh https://github.com/openstack/neutron/blob/master/tools/abandon_old_reviews.sh
--
Sean M. Collins


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Mike Scherbakov

mihgen


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Davanum Srinivas :: https://twitter.com/dims https://twitter.com/dims


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Mike Scherbakov

mihgen


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 17, 2015 by dougwig_at_parksides (7,230 points)   1 2 3
0 votes

Nicely put, Doug, you gave me laughs :)

I can't see how a CR could hang for a month without anyone paying attention
if it worths merging. If this really happens (which I'm not aware of),
auto-abandon definitely won't make things any worse.

--
Best regards,
Oleg Gelbukh

On Fri, Jul 17, 2015 at 6:10 AM, Doug Wiegley dougwig@parksidesoftware.com
wrote:

Just adding an experience from another project, Neutron.

We had similar debates, and prepping for the long apocalyptic winter of
changeset death, Kyle decimated the world and ran the abandon script. The
debates were far more intense than the reality, and my large stockpile of
Rad-X and Nuka Cola went to waste.

Every few weeks, I get a few emails of things being abandoned. And if I
care about something, mine or not, I click through and tap ‘Restore’. If
one person in the entire community can’t be bothered to click one button,
I’m not sure how it’d ever be kept up-to-date, much less merge.

Thanks,
doug

On Jul 16, 2015, at 8:36 PM, Dmitry Borodaenko dborodaenko@mirantis.com
wrote:

I'm with Stanislaw on this one: abandoning reviews just to make numbers
look better will accomplish nothing.

The only benefit I can see is cleaning up reviews that we know don't
need to be considered, so that it's easier for reviewers to find the
reviews that still need attention. I don't see this as that much of a
problem, finding stuff to review in Fuel Review Inbox [0] is not hard at
all.

[0] https://wiki.openstack.org/wiki/Fuel#Development_related_links

And the state of our review backlog is such that it's not safe to
auto-abandon reviews without looking at them, and if a contributor has
spent time looking at a review, abandoning it manually is one click away.

If we do go with setting up an auto-abandon rule, it should be extremely
conservative, for example: CR has a negative vote from a core reviewer AND
there were no comments or positive votes from anyone after that AND it has
not been touched in any way for 2 months.

On Wed, Jul 15, 2015 at 5:10 PM Mike Scherbakov mscherbakov@mirantis.com
wrote:

Folks,
let's execute here. Numbers are still large. Did we have a chance to look
over the whole queue?

Can we go ahead and abandon changes having -1 or -2 from reviewers for
over than a months or so?
I'm all for just following standard OpenStack process [1], and then
change it only if there is good reason for it.

[1] https://wiki.openstack.org/wiki/Puppet#Patch_abandonment_policy

On Thu, Jul 9, 2015 at 6:27 PM Stanislaw Bogatkin sbogatkin@mirantis.com
wrote:

2 weeks seems too small for me. We easy can be in situation when fix for
medium bug is done, but SCF starts. And gap between SCF and release easily
can be more than a month. So, 2 months seems okay for me if speaking about
forcibly applying auto-abandon by major vote. And I'm personally against
such innovation at all.

On Thu, Jul 9, 2015 at 5:37 PM, Davanum Srinivas davanum@gmail.com
wrote:

That's a very good plan ("Initial feedback/triage") Mike.

thanks,
dims

On Thu, Jul 9, 2015 at 3:23 PM, Mike Scherbakov
mscherbakov@mirantis.com wrote:

+1 for just reusing existing script, and adjust it on the way. No
need to
immediately switch from infinite time to a couple of weeks, we can
always
adjust it later. But 1-2 month should be a good start already.

Our current stats [1] look just terrible. Before we enable an
auto-abandon,
we need to go every single patch first, and review it / provide
comment to
authors. The idea is not to abandon some good patches, and not to
offend
contributors...

Let's think how we can approach it. Should we have core reviewers to
check
their corresponding components?

[1] http://stackalytics.com/report/reviews/fuel-group/open

On Wed, Jul 8, 2015 at 1:13 PM Sean M. Collins sean@coreitpro.com
wrote:

Let's keep it at >4 weeks without comment, and Jenkins failed -
similar
to the script that Kyle Mestery uses for Neutron. In fact, we could
actually just use his script ;)

https://github.com/openstack/neutron/blob/master/tools/abandon_old_reviews.sh

--
Sean M. Collins


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Mike Scherbakov

mihgen


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Davanum Srinivas :: https://twitter.com/dims


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Mike Scherbakov

mihgen


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 17, 2015 by Oleg_Gelbukh (3,480 points)   1 2
0 votes

Folks,
I'll push DevOps to run the script. However, what we need is to just go
ahead and clean up, abandon manually what is not relevant anymore, provide
comment.

Please start with your patches.

On Thu, Jul 16, 2015 at 11:08 PM Oleg Gelbukh ogelbukh@mirantis.com wrote:

Nicely put, Doug, you gave me laughs :)

I can't see how a CR could hang for a month without anyone paying
attention if it worths merging. If this really happens (which I'm not aware
of), auto-abandon definitely won't make things any worse.

--
Best regards,
Oleg Gelbukh

On Fri, Jul 17, 2015 at 6:10 AM, Doug Wiegley <
dougwig@parksidesoftware.com> wrote:

Just adding an experience from another project, Neutron.

We had similar debates, and prepping for the long apocalyptic winter of
changeset death, Kyle decimated the world and ran the abandon script. The
debates were far more intense than the reality, and my large stockpile of
Rad-X and Nuka Cola went to waste.

Every few weeks, I get a few emails of things being abandoned. And if I
care about something, mine or not, I click through and tap ‘Restore’. If
one person in the entire community can’t be bothered to click one button,
I’m not sure how it’d ever be kept up-to-date, much less merge.

Thanks,
doug

On Jul 16, 2015, at 8:36 PM, Dmitry Borodaenko dborodaenko@mirantis.com
wrote:

I'm with Stanislaw on this one: abandoning reviews just to make numbers
look better will accomplish nothing.

The only benefit I can see is cleaning up reviews that we know don't
need to be considered, so that it's easier for reviewers to find the
reviews that still need attention. I don't see this as that much of a
problem, finding stuff to review in Fuel Review Inbox [0] is not hard at
all.

[0] https://wiki.openstack.org/wiki/Fuel#Development_related_links

And the state of our review backlog is such that it's not safe to
auto-abandon reviews without looking at them, and if a contributor has
spent time looking at a review, abandoning it manually is one click away.

If we do go with setting up an auto-abandon rule, it should be extremely
conservative, for example: CR has a negative vote from a core reviewer AND
there were no comments or positive votes from anyone after that AND it has
not been touched in any way for 2 months.

On Wed, Jul 15, 2015 at 5:10 PM Mike Scherbakov mscherbakov@mirantis.com
wrote:

Folks,
let's execute here. Numbers are still large. Did we have a chance to
look over the whole queue?

Can we go ahead and abandon changes having -1 or -2 from reviewers for
over than a months or so?
I'm all for just following standard OpenStack process [1], and then
change it only if there is good reason for it.

[1] https://wiki.openstack.org/wiki/Puppet#Patch_abandonment_policy

On Thu, Jul 9, 2015 at 6:27 PM Stanislaw Bogatkin <
sbogatkin@mirantis.com> wrote:

2 weeks seems too small for me. We easy can be in situation when fix
for medium bug is done, but SCF starts. And gap between SCF and release
easily can be more than a month. So, 2 months seems okay for me if speaking
about forcibly applying auto-abandon by major vote. And I'm personally
against such innovation at all.

On Thu, Jul 9, 2015 at 5:37 PM, Davanum Srinivas davanum@gmail.com
wrote:

That's a very good plan ("Initial feedback/triage") Mike.

thanks,
dims

On Thu, Jul 9, 2015 at 3:23 PM, Mike Scherbakov
mscherbakov@mirantis.com wrote:

+1 for just reusing existing script, and adjust it on the way. No
need to
immediately switch from infinite time to a couple of weeks, we can
always
adjust it later. But 1-2 month should be a good start already.

Our current stats [1] look just terrible. Before we enable an
auto-abandon,
we need to go every single patch first, and review it / provide
comment to
authors. The idea is not to abandon some good patches, and not to
offend
contributors...

Let's think how we can approach it. Should we have core reviewers to
check
their corresponding components?

[1] http://stackalytics.com/report/reviews/fuel-group/open

On Wed, Jul 8, 2015 at 1:13 PM Sean M. Collins sean@coreitpro.com
wrote:

Let's keep it at >4 weeks without comment, and Jenkins failed -
similar
to the script that Kyle Mestery uses for Neutron. In fact, we could
actually just use his script ;)

https://github.com/openstack/neutron/blob/master/tools/abandon_old_reviews.sh

--
Sean M. Collins


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Mike Scherbakov

mihgen


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Davanum Srinivas :: https://twitter.com/dims


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Mike Scherbakov

mihgen


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Mike Scherbakov

mihgen


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 22, 2015 by Mike_Scherbakov (9,460 points)   1 4 6
...