Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

2016-02-17 Thread Stefano Maffulli
On 02/05/2016 07:17 PM, Doug Hellmann wrote:
> So, is Poppy "open core"?

I think it's a simple answer: no, Poppy is not open core.

Poppy is not open core... Is Linux Open Core because you have to buy a
processor and ram to run it?

Or is Firefox open core because I have to buy service from a bank before
I can use an online banking system?

A better question to ask is whether it fits in OpenStack given that
Poppy's open source code can only be tested by the community if the
community buys some/all those CDNs.


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Stefano Maffulli
On 01/12/2016 06:13 AM, Amrith Kumar wrote:
> I did not exhaustively verify this but 

A fair question to ask then is, why are you proposing these patches?

> I created a quick poll to tally results

oh no, not another survey! :) Sometimes I feel that survey-itis[1] is a
consequence of the chronic meeting-itis[2] that OpenStack suffers from.


[1] a disease of online communities whose leaders are afraid to take
actions and revert to online polls before making any decision. It's
caused by the same pathogens that forces governments to appeal to the
interests and conceptions (such as hopes and fears) of the general
population (see populism).
[2] another disease

OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] Gerrit Upgrade 12/16

2015-12-01 Thread Stefano Maffulli
On 12/01/2015 06:38 PM, Spencer Krum wrote:
> There is a thread beginning here:
> which covers what to expect from the new software.

Nice! This is awesome: the new review panel lets you edit files on the
web interface. No more `git review -d` and subsequent commit to fix a
typo. I think this is huge for documentation and all sort of nitpicking :)

And while I'm at it, I respectfully bow to the infra team: keeping pace
with frequent software upgrades at this size is no small feat and a rare
accomplishment. Good job.


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [tc][all] Tags, explain like I am five?

2015-07-15 Thread Stefano Maffulli
On 07/15/2015 11:25 AM, Joshua Harlow wrote:
 So I've been following the TC work on tags, and have been slightly
 confused by the whole work, so I am wondering if I can get a
 'explainlikeimfive' (borrowing from reddit terminology) edition of it.

I'll try :)

You need to think of tags as the labels on the boxes containing your
toys: you'll have a box with legos, one box with dolls, one box with
bicycle parts, one with star wars figurines etc. Each box with a label
outside so you can read (at 5 you may be able to read) what is in the
box before you open it.

Does that make sense?

You may think that the tags are to identify the toys you like the most
but that's not the purpose. You may like Skywalker figurine but dislike
Yoda, but they're both going to be in the starwars box. Starwars is an
objective way for dad and your friends to understand which toys go in
which bucket. Since you may like something today and not tomorrow, and
since dad can't read your mind we don't use labels such as things I
like a lot or things I hate because those are subjective valuations.

Are you still there? :)

 I always thought tags were going to be something like:

The graphic you used obviously carries subjective meaning, which tags
are never meant to be and hopefully never will.

The 'tags' are defined on the spec:

On that spec there is spelled out the problem that the tags are
introduced to solve.  Tags are to represent a precise *taxonomy* to
navigate the OpenStack ecosystem, to help readers understand how a
project is managed (does it have a vulnerability team assigned? does it
keep a stable branch? what's the release model? Is it overseen by the
TC? etc). As the spec says:

the landscape [used to be]is very simple: you’re in the integrated
release, or you’re not. But since there was only one category (or
badge of honor), it ended up meaning different things to different

In Thierry's words to [Openstack-operators] [tags] Ops-Data vs.
Ops-Tags, June 16 2015:

They come with a definition, a set of requirements that a project
must fulfill to be granted the label. Ideally the requirements are
objective, based on available documentation and metrics. But the
tag definition itself remains subjective.

The tags are called to describe objectively each project. So, for
example, if you want to know which project maintain a stable branch, you
see the list on:

You want to see if projects are libraries, middleware or client:

Are you curious to see which projects constitute the release approved by
the TC?

Tags can be proposed by anyone, not only by the TC and they get
discussed and voted on gerrit. The proposed tags need to be as objective
as possible. And there is a working group
( among operators
trying to define tags that may help operators to judge if a project is
good for them to use or not.


OpenStack Development Mailing List (not for usage questions)

[openstack-dev] [all] Proper escalation venues for stuck reviews

2015-05-28 Thread Stefano Maffulli
First of all a reminder to everybody doing code reviews:

 Avoid sarcasm and jokes

Those travel poorly across TCP/IP and don't translate well in different
languages. Just don't use them.

If you get a negative vote or comments you don't like/understand ask for
more explanations. Offer a place and venue to discuss it more. IRC chat
or phone conversation (followed by written resolution on the review
itself) will go a long way to clarify things.

If you're *giving* a negative comment, offer a place and venue to
discuss it more, like above.

If the disagreement persists, simply agree to disagree: nobody ever
changes their mind based on someone else repeating the same thing over
and over. The way to move the conversation forward is to escalate to
PTLs and the Developer Advocate/Community Manager.

Friendly yours,

OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [cinder] Deadline For New Cinder Volume Drivers in Liberty

2015-05-13 Thread Stefano Maffulli
On 05/13/2015 11:48 AM, Mike Perez wrote:
 The Cinder team has met today [1] to begin discussions on the deadline
 for new volume drivers in the Liberty release.
 The proposed deadline for volume drivers to be merged by is June 19th 2015

Great to read this, thanks Mike.

On a wider note, I think we should have a more institutional place to
communicate this sort of important decisions than the mailing list only.
I'm thinking of proposing a new scope for the OpenStack blog for this.

We used to use the blog as the main source of communication, from
Foundation, events, community-related news and the weekly newsletter.
Recently the Foundation has added two new important publication: and These end
up taking lots of the content that was on the blog.

I think that we might tighten the focus of the blog to contributors and
operators (and app developers) aspects, use it as the regular platform
for TC communication, PTLs and community managers to communicate
relevant news.



OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all] cross project communication: periodic developer newsletter?

2015-05-04 Thread Stefano Maffulli
Thanks Joe for bringing this up. I have always tried to find topics
worth being covered in the weekly newsletter. I assemble that newsletter
thinking of developers and operators as the main targets, I'd like both
audiences to have one place to look at weekly and skim rapidly to see if
they missed something interesting.

Over the years I have tried to change it based on feedback I received so
this conversation is great to have

On 05/04/2015 12:03 PM, Joe Gordon wrote:
 The  big questions I would like to see answered are:
 * What are the big challenges each project is currently working on?
 * What can we learn from each other?
 * Where are individual projects trying to solve the same problem

These are all important and interesting questions. When there were fewer
projects it wasn't too hard to keep things together. Nowadays there is a
lot more going on and in gerrit, which requires a bit more upfront
investment to be useful.

 To answer these questions one needs to look at a lot of sources, including:
 * Weekly meeting logs, or hopefully just the notes assuming we get
 better at taking detailed notes

I counted over 80 meetings each week: if they all took excellent notes,
with clear #info lines for the relevant stuff, one person would be able
probably to parse them all in a couple hours every week to identify
items worth reporting.

My experience is that IRC meeting logs don't convey anything useful to
outsiders. Pick any project log from and you'll see what I mean.
Even the best ones don't really mean much to those not into the project

I am very skeptical that we can educate all meeting participants to take
notes that can be meaningful to outsiders. I am also not sure that the
IRC meeting notes are the right place for this.

Maybe it would make more sense to educate PTLs and liasons to nudge me
with a brief email or log in some sort of notification bucket a quick
snippet of text to share with the rest of the contributors.

 * approved specs

More than the approved ones, which are easy to spot on, I think the new ones proposed are more interesting.

Ideally I would find a way to publish draft specs on or somehow provide a way for uneducated (to
gerrit) readers to more easily discover what's coming.

Until a better technical solution exists, I can pull regularly from all
status:open changesets from *-specs repositories and put them in a
section of the weekly newsletter.

 * periodically talk to the PTL of each project to see if any big
 discussions were discussed else where

I think this already happen in the xproject meeting, doesn't it?

 * Topics selected for discussion at summits

I'm confused about this: aren't these visible already as part of the

 Off the top of my head here are a few topics that would make good
 candidates for this newsletter:
 * What are different projects doing with microversioned APIs, I know
 that at least two projects are tackling this
 * How has the specs process evolved in each project, we all started out
 from a common point but seem to have all gone in slightly different
 * What will each projects priorities be in Liberty? Do any of them overlap?
 * Any process changes that projects have tried that worked or didn't work
 * How is functional testing evolving in each project

Great to have precise examples to work with. It's useful exercise to
start from the end and trace back to where the answer will be. How would
the answer to these question look like?

 Would this help with cross project communication? Is this feasible?
 Other thoughts?

I think it would help, it is feasible. Let's keep the ideas rolling :)


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates

2015-04-30 Thread Stefano Maffulli
On Thu, 2015-04-30 at 12:26 +0200, Flavio Percoco wrote:
 I've seen the number of threads to discuss Ops topics increase in
 openstack-dev and the influence of Ops - even just points of views
 inherited from the feedback we've got - on reviews has gotten better
 as well.

Fantastic, that has always been the intention.

 If it's a matter of having more Ops voting for the TC, we do have a
 process in place that we could likely improve. Other than that, I
 believe Thierry and Doug have explained perfectly the issues related
 to having these 2 groups merged from a *governance* perspective.

I noticed that this round of elections we had TC *candidates* that at
least I consider more operators than strictly 'dev'. That, to me, is a
huge sign of the progress we've made to integrate the two categories. 

To me the real big question is: how are candidates from the operators
side going to get a better chance of being elected next time? 

And what's the role of the User Committee in all this?


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all] Question for the TC candidates

2015-04-29 Thread Stefano Maffulli
On Wed, 2015-04-29 at 12:59 +0300, Maish Saidel-Keesing wrote:
 Again my apologies for the incorrect format - since I am still not
 receiving the messages from this thread.

let me know if you want me to investigate this further.

 Doug - evidently this is not working as it should. As Chris said as
 well - the posts are not tagged and are not regular. 

I'd like to move the conversation to practical examples because in
theory we all agree that communication is key and can be improved.

In practice, that's hard and it's better to talk about specific

 They were not noticed - because they didn't really happen.
I sense that they happened until there were things fairly easy to
communicate. Are there been significant discussions in TC meetings? Yes,
the big tent and the accompanying tag system is the only one I can think
of. Were they worth a blog post? Yes. Was that blog post easy to write?
No because the topic has been under development for quite some time with
not enough clear roadmap to write a summary for wider consumption. If a
blog post comes out saying something half-baked over a change so
important, the TC members will be distracted by noise from people not
involved enough to understand the challenges. There is always a fine
balance to strike between being open and being effective.

Considering that all TC members are volunteers with day jobs, get busier
and busier as the release approaches, I'm really not surprised that the
TC has scheduled time to present the progress on the 'big tent' and tags
in person at events (the operators summit in PHL) and in Vancouver.

IMHO the topic is getting clear enough to be summarized in 500-700 words
blog post only in the past weeks... 

The thing is that tags and big tent have been discussed widely *outside*
of the TC, I think nobody interested in the OpenStack governance issues
may have missed the fact that such conversation was happening. They may
have missed the *details* but not missed the existence of the
conversation itself.

what other topic has the TC discussed and decided upon that have you not
seen announced?

 If the audience that you are planning on communicating with is: not
 the developers themselves and those who are already heavily involved
 in the community - I think this certainly is not the place to
 publicize changes. Do you seriously expect people who are trying to
 find information (not as a regular code contributor) about what is
 going on to start delving through Gerrit? 

Maybe we should document better how to get notifications of new
discussions on the governance repository. I could also start including
the proposals pending for review in the newsletter so people can at
least skim through the commit titles weekly.

If you check the latest changes though you'll see how much of that is
really not important:,n,z

the important ones I find in 2015: Add the release naming process Add IRC channel policies

a few new project teams added and the tag-stuff, like Move from program-based structure to
project-based Introduce tag attributes Add template for project taxonomy
tags definition


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all] Question for the TC candidates

2015-04-29 Thread Stefano Maffulli
On Wed, 2015-04-29 at 18:28 +0300, Maish Saidel-Keesing wrote:
 How about the fact that the definition of an ATC was changed [1] for a 
 free Summit pass? [2]

This was not a decision of the TC, it was a decision of the Foundation
staff. The definition of ATC has *not* changed, that's embedded in the

And who gets the pass hasn't changed much either: people who are
*actively* committing code and documentation to OpenStack have received
an invite. 

Previously we have considered *actively* committing code and docs ==
ATC. For this cycle the Foundation staff started considering better ways
to identify those that actually contribute to the design discussions. 

The details of who gets a free invite may change again in the future
because we want to keep the Open promises, without compromising the


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all] Question for the TC candidates

2015-04-28 Thread Stefano Maffulli
On Mon, 2015-04-27 at 17:00 -0400, Doug Hellmann wrote:
 I would have to go back and check, but I'm pretty sure the posts were
 highlighted in Stef's community newsletter email. 

They were, in fact. But I know as a fact that even if people many love
the newsletter, I have the impression that few people follow the links.
The blog posts from the TC were on, on, relayed on twitter and mentioned in the weekly
newsletter. I don't think we can give more visibility than this without
getting annoying. Maybe better titles and leads in the posts would help

The problem is that there is just too much traffic and it's impossible
for anyone to keep up with everything. People skim through their emails
checking the subjects, their rss feeds reading only the titles, parsing
twitter feed for a couple of pages down (at best) and that's it. If
nothing catches their attention, pieces of information get lost. Even
the weekly newsletter I'm sure few people click to follow the links and
read further (unless it has a cool title).

I've long come to the conclusion that it is what it is: at the size
we're at, we can't expect every voter to be fully informed about all the

Better titles and a sort of TL;DR first paragraph in blog posts are very
helpful. But in order to write those, the author needs to have more
training as a communicator and more time. It's just a hard problem.


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all] Question for the TC candidates

2015-04-28 Thread Stefano Maffulli
On Tue, 2015-04-28 at 16:30 +0100, Chris Dent wrote:
 What's important to avoid is the blog postings being only reporting of
 conclusions. They also need to be invitations to participate in the
 discussions. Yes, the mailing list, gerrit and meeting logs have some
 of the ongoing discussions but often, without a nudge, people won't

Not being a member of the TC, I have noticed that the hottest topics
touched by the TC were indeed discussed on this list quite extensively.
I'm sure you've not missed the conversation about big tent, tags,
release naming process, the use of secret IRC channels, etc. Important
conversations happen on this list first, then move to the tc and
eventually become decisions published on

Applications of new projects also are discussed on this list before they
land on TC meeting agenda.

The mailing list of the TC is open and is low traffic. The agenda is
published there regularly: people who care about the TC and *have time
to spare* are on that list. 

If you haven't seen many blog posts in 2015 is because the most
important change is the 'big tent' and its tagging system. My feeling is
that this topic is so huge that it will take another cycle before it can
be digested, nobody yet considers it 'completed' enough to summarize in
a blog post. I expect that after the release and the Summit the topic
will be more clear. BTW, add this session to your calendar for

 I'm not trying to suggest that the TC is trying to keep people in
 the dark, rather that it always takes more effort than anyone would
 like to make sure things are lit.

I have the feeling that the largest and most important changes are being
communicated widely. They're hard and complex and will require time and
more efforts by all (not just TC members) before they're also understood
properly. It'll take time.


OpenStack Development Mailing List (not for usage questions)

[openstack-dev] [metrics] what answers do you expect from counting comments? (was Re: Please stop reviewing code while asking questions)

2015-04-24 Thread Stefano Maffulli
On Fri, 2015-04-24 at 15:02 +, Amrith Kumar wrote:
 I would support changes to both reviewstats and stackalytics to do the
 1. recognizes and gives credit to '0' comments
 2. identifies recheck, reverify and similar directives to the CI
 system and flag them appropriately, potentially as not being reviews
 but something else. 

I'm intrigued by this request. In the Quarterly Activity Reports[1] I am
more interested in time to merge (the time for a changeset to go from
first proposal to merged), time to respond (for human interations in
comments) and iterations (how many patchsets in a changeset). 

I wonder if I should expand the scope of the reports.  Can you elaborate
why you are interested in this sort of count?



OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] Regarding finding Mentors

2015-03-31 Thread Stefano Maffulli
On Sat, 2015-03-28 at 19:58 +0530, Ganesh R wrote:
 I am a newbie to OpenStack, very interested in contributing to
 OpenStack development.

Jeremy provided some useful suggestions. Just last week I added to how
to contribute page the links to mentors page:

 To proceed further, I thought it will be good to have a mentor with
 whom I can work.

I'd suggest you to start by hanging out on IRC #openstack-101 and ask
questions there.

I've been working on a checklist for first time contributors:

I would appreciate your help to validate and complete it as you go on
with your quest :)

I'm reed on IRC, happy to talk to you more.


OpenStack Development Mailing List (not for usage questions)

[openstack-dev] Find your discount code for Vancouver and register *now*

2015-03-30 Thread Stefano Maffulli

If you have received your discount code to OpenStack summit Vancouver,
stop whatever you're doing and

register *now* 

Admission prices go up to $900 tomorrow and you'll have to pay the
difference. *There will be absolutely no exceptions*.

If you're in doubt if you should have received an invite check

and if you think you qualify for an invite reply to and provide a URL to your merged
contributions. No link to bugs or blueprints: *only merged contributions
matter* and URL to


OpenStack Development Mailing List (not for usage questions)

[openstack-dev] Beyond IRC (was Re: Cinder Third-Party CI: what next?)

2015-03-24 Thread Stefano Maffulli
On Tue, 2015-03-24 at 19:01 +, Rochelle Grober wrote:
 So, how do we get timely first core review of patches in areas of the
 world where Core presence in IRC is slim to none?

I think that most core reviewers use bouncers, so notifying them in the
channel would probably raise a notification in their clients when they
connect back. I understand the feeling though: as the sender of a
message over IRC, I have no good way to understand if the message was
delivered to the recipient as expected.

I'd start with advising to use the bouncer and ping the core reviewers
on channel with review requests. (more about this below)
 I can think of a few options but they don’t seem great:  
 ·A filter for dashboards that flags reviews with multiple +1s
 and no core along with a commitment of the Core team to perform a
 review within x number of days
This might work, modulo the 'committment' of core team which I think
cannot go above a best effort.

 ·A separate mailing list for project review requests

I'm skeptical about this being effective: just another source of
incoming email that needs to be filtered out (at which point a mailman
topic would have the same effect).

 ·Somehow queueing requests in the IRC channel so that offline
 developers can easily find review requests when looking at channel

Maybe we can hack an IRC bot so that it collects review requests and
lists them on eavesdrop? Something like a user on irc writes:

: please review https://URL because it's needed for GOODREASONS #review

and on a web page like we add 'requests
for reviews', maybe an rss feed.

BTW, Thierry had a similar request a few weeks back for a system to
quickly share 'good news' and create a stream of reasons for
happyness :)
 Solving this issue could help not just Third Party developers, but all
 of OpenStack and make the community more inviting to Asian and
 Australian (and maybe European and African) developers.

In general, make it more resilient and asynchronous, not just because of


OpenStack Development Mailing List (not for usage questions)

[openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

2015-03-23 Thread Stefano Maffulli
On Mon, 2015-03-23 at 11:43 -0700, Mike Perez wrote:
 We've been talking about CI's for a year. We started talking about CI 
 in August. If you post a driver for Kilo, it was communicated that you're
 required to have a CI by the end of Kilo [1][2][3][4][5][6][7][8]. This
 should've been known by your engineers regardless of when you submitted your

Let's work to fix the CI bits for Liberty and beyond. I have the feeling
that despite your best effort to communicate deadlines, some quite
visible failure has happened. 

You've been clear about Cinder's deadlines, I've been trying to add them
also to the weekly newsletter, too. 

To the people whose drivers don't have their CI completed in time: what
do you suggest should change so that you won't miss the deadlines in the
future? How should the processes and tool be different so you'll be
successful with your OpenStack-based products?


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] Cinder Third-Party CI: what next?

2015-03-23 Thread Stefano Maffulli
On Mon, 2015-03-23 at 16:23 -0400, Anita Kuno wrote:
 Some folks just will not respect other people's time. To pretend
 otherwise is a huge dis-service to folks trying their hardest to
 support those worthy of the support.

This may be true in general but I have yet to be convinced that this is
the case. My impression is that the situation is more complex than just
lack of respect for other people's time.

 I'm really disappointed that there hasn't been more support for Mike
 in this process.

I've been supporting Mike in this decision and have not seen any element
that makes me believe that Mike's position is not supported. Where have
you seen lack of support?

Going back to the point, in Paris I have been told that deadlines are
hard to know. We've changed and this time you and Mike and cinder core
and the whole Third-Party-CI team have been doing a lot more than in the
past to keep people informed about deadlines, offering help,
documentation, mentoring, etc. 

And still, that was not enough for some major members of OpenStack who
failed to meet the deadlines.  That's why I am *not* asking you or Mike
what you can do better. 

I'm asking the folks at NetApp, Huawei and others to tell us what they
think should be done differently.


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] Avoiding regression in project governance

2015-03-11 Thread Stefano Maffulli
On Tue, 2015-03-10 at 15:23 -0700, James E. Blair wrote:
 The holy grail of this system would be the suitable for production
 deployment tag, but no one has figured out how to define it yet.

Are crazy ideas welcome in this phase?

I start with 2 below: 

Preface: an idea circulates about visually displaying in a web page the
projects.yaml file and the tags in there. Visitors would be able to
browse the list of projects and sort, pick, search and find what they
need from a nice representation of the 'big tent'. 

1) how about we pull the popularity of OpenStack projects as reported in
the User Survey and display such number on the page where we list the
projects? What if, together with the objective tags managed by TC and
community at large, we show also the number of known deployment as

2) there are some 'fairly objective' indicators of quality of open
source code, developed in a handful of academic projects that I'm aware
of (Calipso and come to mind, but there are other).
Maybe we can build a tool that pulls those metrics from each of our
repositories and provides more guidance to visitors so they can form
their own mind?

Nobody can really vet for 'production ready' but probably we can provide
data for someone to get a more informed opinion. Too crazy? 


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] Avoiding regression in project governance

2015-03-11 Thread Stefano Maffulli
On Wed, 2015-03-11 at 17:59 -0500, Ed Leafe wrote:
 The longer we try to be both sides of this process, the longer we will
 continue to have these back-and-forths about stability vs. innovation.

If I understand correctly your model, it works only for users/operators
who decide to rely on a vendor to consume OpenStack. There are quite
large enterprises out there who consume directly the code as it's
shipped from, some from trunk others from the stable
release .tgz: these guys can't count on companies A, B, C or D to put
resources to fix their problems, because they don't talk to those

One thing I like of your proposal though, when you say:

 So what is production-ready? And how would you trust any such
 designation? I think that it should be the responsibility of groups
 outside of OpenStack development to make that call. 

This problem has been bugging the European authorities for a long time
and they've invested quite a lot of money to find tools that would help
IT managers of the public (and private) sector estimate the quality of
open source code. It's a big deal in fact when on one hand you have
Microsoft and IBM sales folks selling your IT managers overpriced stuff
that just works and on the other hand you have this Linux thing that
nobody has heard of, it's gratis and I can find it on the web and many
say it just works, too... crazy, right? Well, at the time it was and
to some extent, it still is. So the EU has funded lots of research in
this area.

One group of researcher that I happen to be familiar with, recently has
received another bag of Euros and released code/methodologies to
evaluate and compare open source projects[1]. The principles they use to
evaluate software are not that hard to find and are quite objective. For
example: is there a book published about this project? If there is,
chances are this project is popular enough for a publisher to sell
copies. Is the project's documentation translated in multiple languages?
Then we can assume the project is popular. How long has the code been
around? How large is the pool of contributors? Are there training
programs offered? You get the gist.

Following up on my previous crazy ideas (did I hear someone yell keep
'em coming?), probably a set of tags like:

   book-exists (or book-chapter-exists)
   translated-in-1-language (and its bigger brothers translated-in-5,
   contributor-size-high (or low, and we can set a rule as we do for the
diversity metric used in incubation/graduation)
   codebase-age-baby, -young and  -mature,  (in classes, like less than
1, 1-3, 3+ years old)

would help a user understand that Nova or Neutron are different from
(say) Barbican or Zaqar. These are just statements of facts, not a
qualitative assessment of any of the projects mentioned. At the same
time, I have the impression these facts would help our users make up
their mind.



Description: This is a digitally signed message part
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [cinder]difference between spec merged and BP approval

2015-03-10 Thread Stefano Maffulli
Hi David,

On Sat, 2015-03-07 at 02:22 +, Chen, Wei D wrote:
 I thought the feature should be approved as long as the SPEC[1] is
 merged, but it seems I am wrong from the beginning[2], both of
 them (SPEC merged and BP approval[4][5]) is necessary and mandatory
 for getting some effective reviews, right? anyone can help to
 confirm with that?

Since Cinder uses BP+spec, the process is described on the wiki page:

If it helps, I'd consider the spec and the blueprint as one element
made of two pieces. The spec needs to be approved and its
corresponding blueprint needs to be approved and have a priority,
deadline/milestone assigned. If any of these attributes is missing, the
feature is not going to be reviewed.

Blueprints and their attributes 'priority' and 'milestone' are used to
track the status of the release. The reviewers use BPs to identify the
code that they need to review. For example,

I've tried to piece the history of your experience from the links you

- you submitted the spec in November 2014
- the spec was approved on Jan 6, 2015 (from
- the spec references two blueprints, one for Cinder, one of
Cinder-client; both BPs were created at the end of February
- none of the BP have a milestone set
- you submitted code related to the approved spec between Jan 6 and

I have the impression that you may have missed a step in the BP+spec
process. I have tried to find the documentation for this process myself
and I had a hard time, too.

 Besides, who is eligible to define/modify the priority in the list[3],
 only PTL or any core? I am trying to understand the
 acceptable procedure for the coming 'L'.

The project team leaders (PTL) are ultimately responsible to set the
priorities, although the decision is always a consensual decision of the
core teams.

Have you considered joining OpenStack Upstream Training?


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [devstack]Specific Juno version

2015-03-04 Thread Stefano Maffulli
On Tue, 2015-03-03 at 17:42 +0200, Eduard Matei wrote:

 Is there a way to specify the Juno version to be installed using

Let's please reserve this list for discussions about the *future* of
OpenStack development, not questions about using its tools. 

Please, everybody, help us stay on topic.

 This email and any files transmitted with it are confidential and
 intended solely for the use of the individual or entity to whom they
 are addressed.

No, they're not: you sent this message to a public mailing list,
archived publicly with no barriers for any archiver, spider, spammer and
casual human reader. The email you just sent is intended for public use
and consumption. 


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] Gerrit tooling improvements

2015-03-03 Thread Stefano Maffulli
On Tue, 2015-03-03 at 17:10 +0200, Duncan Thomas wrote:
 I feel the need to abandon changes that seem abandoned

I think there is an agreement that there should be a way to have a clean
view of changesets that are being actively worked on, changes where the
owner is responding to comments, working on it, rebasing as needed, or
waiting for votes/comments.  

For contributors, including the slow ones, I think nobody would object
that it's also good for them to login on
and see the list of their changesets, with votes and comments up where
they left them (instead of in the Recently closed).

So I think we go back to tooling: hopefully new version of gerrit will
have a better way to distinguish 'abandoned' from 'inactive'. Until
then, what other options do we have?


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

2015-03-02 Thread Stefano Maffulli
On Mon, 2015-03-02 at 13:35 -0800, Clay Gerrard wrote:
 I think Tom's suggested help us help you is a great pre-abandon
 warning.  In swift as often as not the last message ended with
 something like you can catch me on freenode in #openstack-swift if
 you have any questions  
Good, this thread is starting to converge.
 But I really can't fathom what's the harm in closing abandoned patches
 as abandoned?

Jim Blair gave a lot of good reasons for not abandoning *automatically*
and instead leave the decision to abandon to humans only. 

His message is worth reading again:


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] auto-abandon changesets considered harmful

2015-03-02 Thread Stefano Maffulli
On Mon, 2015-03-02 at 12:00 -0700, Doug Wiegley wrote:
 Why do you feel the need to keep them?  Do your regularly look at
 older patches? Do you know anyone that does?
I don't think that's the point. The point is to try improving
contributor's life by providing them one last useful comment before
ignoring their contribution for good.

Tom gave a good suggestion IMHO and I've found a couple of cases where
maybe if someone reached out to the contributor and offered some help
probably their patch would have merged (or they would have learned a
useful, explicit lesson). Instead auto-abandon has *implicit*
connotation: a contributor may never know exactly why that patch was

I suggest to give a second look at Tom's proposal because I think it
doesn't add any more workload on reviewers but provides for a clean exit
to a lagging changeset. 


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle [metrics]

2015-02-27 Thread Stefano Maffulli
On Thu, 2015-02-26 at 16:44 -0800, James E. Blair wrote:
 It is good to recognize the impact of this, however, I would suggest
 that if having open changes that are not actively being worked is a
 problem for statistics,

I don't think it's a problem for the statistics per se. The reports are
only a tool to analyze complex phenomenons and translate them into
manageable items. In fact, we keep adding more stats as we go because
every chart and table leaves us with more questions.

  let's change the statistics calculation.  Please do not abandon the
 work of contributors to improve the appearance of
 these metrics.  Instead, simply decide what criteria you think should
 apply and exclude those changes from your calculations.

I'm currently thinking that it would be informative to plot the
distribution of the efficiency metrics, instead of simply come up with a
filter to ignore long standing changes with slow/null activity over some
arbitrary amount of time. I think it would be more interesting to see
how many 'inactive' vs 'active' there are at a given time.

In any case, since Sean said that nova (and other projects) already
remove unmergeable changesets regularly, I think the data are already
clean enough to give us food for thoughts.

Why owners seem to be getting slower and slower to provide new patches,
despite the fact that the number of patches per changeset is fairly
stable? I'll look into the data more carefully with Daniel Izquierdo as
I think there are huge outliers skewing the data (the diff between
median and average is huge).


OpenStack Development Mailing List (not for usage questions)

[openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

2015-02-27 Thread Stefano Maffulli
I'm not expressing myself cleary enough. I don't advocate for the
removal of anything because I like pretty charts. I'm changing the
subject to be even more clear.

On Fri, 2015-02-27 at 13:26 -0800, James E. Blair wrote:
 I am asking you to please independently remove changes that you don't
 think should be considered from your metrics.  

I'm saying that the reports have indicators that seem to show struggle.
In a previous message Kevin hinted that probably a reason for those bad
looking numbers was due to a lot of reviews that appear to have been
abandoned. This doesn't seem the case because some projects have a
habit of 'purging'. 

I have never explicitly ordered developers to purge anything. If their
decision to purge is due to the numbers they may have seen on the
reports I'd like to know. 

That said, the problem that the reports highlight remains confirmed so
far: contributors seem to be left in some cases hanging, for many many
days, *after a comment* and they don't come back.

 I think abandoning changes so that the metrics look the way we want is a
 terrible experience for contributors.

I agree, that should not be a motivator. Also, after chatting with you
on IRC I tend to think that instead of abandoning the review we should
highlight them and have humans act on them. Maybe build a dashboard of
'old stuff' to periodically sift through and see if there are things
worth picking up again or to ping the owner or something else managed by

I happened to have found one of such review automatically closed that
could have been fixed with a trivial edit in commit message instead:

(that owner had a bunch of auto-abandoned patches,n,z). I have made a note to reach out to him and
get more anecdotes.

 Especially as it appears some projects, such as nova, are in a position
 where they are actually leaving -2 votes on changes which will not be
 lifted for 2 or 3 months.  That means that if someone runs a script like
 Sean's, these changes will be abandoned, yet there is nothing that the
 submitter can do to progress the change in the mean time.  Abandoning
 such a review is making an already bad experience for contributors even

this sounds like a different issue :(

OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle [metrics]

2015-02-26 Thread Stefano Maffulli
On Thu, 2015-02-26 at 15:58 -0600, Kevin L. Mitchell wrote:
 One thing that comes to mind is that there are a lot of reviews that
 appear to have been abandoned; I just cleared several from the
 novaclient review queue (or commented on them to see if they were still
 alive).  I also know of a few novaclient changes that are waiting for
 corresponding nova changes before they can be merged.  Could these be
 introducing a skew factor?

Maybe, depending on how many they are and how old are we talking about.
How much cruft is there? Maybe the fact that we don't autoabandon
anymore is a relevant factor?

Looking at Nova time to merge (not the client, since clients are not
analyzed individually), the median is over 10 days (the mean wait is
29). But if you look at the trends of time to way for reviewers, they've
been trending down for 3 quarters in a row (both, average and median)
while time to wait for submitter is trending up.

Does it make sense to purge old stuff regularly so we have a better
overview? Or maybe we should chart a distribution of age of proposed
changesets, too in order to get a better understanding of where the
outliers are?


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle [metrics]

2015-02-26 Thread Stefano Maffulli
On Thu, 2015-02-26 at 14:18 -0600, Anne Gentle wrote:
 Do the features listed in the Release Notes each have appropriate
 documentation? So far we just link to the specifications for nova, for
 example. [1] So to me, it could be a focus on the specification
 acceptance means less time/energy for the actual user-facing docs.
Great question. I have no idea of how we can correlate blueprints/specs
completed and the existence of accompanying doc. The tool we have now
scans git repositories and launchpad (will soon scan storyboard, too):
what data is in there that this tool can use to guess documentation

Happy to brainstorm this with you and Bitergia's Jesus and Daniel as
they may have ideas.


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle [metrics]

2015-02-26 Thread Stefano Maffulli
On Wed, 2015-02-25 at 21:15 +, Ian Cordasco wrote:
 I read it the same was as Doug. I don’t think Jeremy was trying to
 imply your reviews would move through more quickly if you reviewed
 other people’s work. Just that, as with most open source projects,
 there’s always at least 2 distinct groups: people who push code more
 often and people who review code more often. 

this conversation reminded me that the median time to merge new code has
been increasing every quarter in the past year, but dropped for the
first time during last quarter (table and chart on page 23 of Q4
quarterly report [1]). The mean number of iterations (patchsets) per
proposed change has also decreased for the first time in Q4 2014.

The interesting bit of those charts is that overall for OpenStack
projects, it seems that the reviews (comments to patchsets) are arriving
quite quickly but the new patchsets take a lot more to be submitted. 

Too much debating and commenting over each patch? Or are the
authors/owners of the changeset slow to respond with new patches? I
don't have an answer. I'd be happy to look at the data with other

I think more analysis is needed before we can identify and remove the


The analysis doesn't count the *-specs repositories, only code and docs.

PS The analysis of the individual projects are in their own pdf

OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all] creating a unified developer reference manual

2015-02-26 Thread Stefano Maffulli
On Wed, 2015-02-25 at 14:54 -0500, Doug Hellmann wrote:
 1. Should we have a unified developer guide for the project?

Yes. Absolutely. Yes.

 2. Where should it live and how should we manage it?

I think the natural destination for it would be the URL (which should be instead
named /contributor to avoid collision with

I started playing around with an entry portal for new contributors, one
that would give a clear path (think a ladder) from setup dev environment
to first code reviews to full on core member. Since we teach this stuff
at Upstream Training, I used the timeline in the class to start
assembling a table of content for a new contributor's guide

 I believe we would benefit by having a more formal place to write down
 some of our experiences in ways that make them discoverable. We have
 been using the wiki for this, but it is often challenging to find
 information in the wiki if you don’t generally know where to look for

The problem is that some stuff is in the wiki (which can be and is being
improved, btw) and some other stuff is scattered around and often
duplicated in project's repos. 

 That leads to an answer to question 2: create a new git repository to
 host a Sphinx-based manual similar to what many projects already have.
 We would then try to unify content from all sources where it applies
 to the whole project, and we could eventually start moving some of the
 wiki content into it as well.

This sounds like a good approach to me already. Unless someone has
better alternatives, I'd go for it.

 If we decide to create the repository, we would also need to decide
 how it would be managed. The rules set up for the cross-project specs
 repository seems close to what we want (everyone can +1/-1; TC members
 can +2/-2; the TC chair tallies the votes and uses workflow+1) [4].

Sounds good to me, at least to get started. At some point the people who
care the most for this effort will emerge and maybe the TC will give the
+w also to them.


OpenStack Development Mailing List (not for usage questions)

[openstack-dev] Call for mentors - Upstream Training, Google Summer of Code, Outreachy (AKA OPW) [all]

2015-02-19 Thread Stefano Maffulli
Hello folks

we have a bunch of upcoming initiatives to help out new contributors to
OpenStack and we need mentors willing to help newcomers go from zero to
(at least) one merged patch.

OpenStack has always been a welcoming community despite being complex to
navigate for new contributors. If you remember your first patch you know
what I mean :) If you want to spare a fellow colleague some of that
pain, consider adding your name to this wiki page:

I and other volunteers will be contacting you to help in the specific
programs mentioned in the subject.


OpenStack Development Mailing List (not for usage questions)

[openstack-dev] The root-cause for IRC private channels (was Re: [all][tc] Lets keep our community open, lets fight for it)

2015-02-17 Thread Stefano Maffulli
Changing the subject since Flavio's call for openness was broader than
just private IRC channels.

On Tue, 2015-02-17 at 10:37 +, Daniel P. Berrange wrote:
 If cases of bad community behaviour, such as use of passwd protected
 IRC channels, are always primarily dealt with via further private
 communications, then we are denying the voters the information they
 need to hold people to account. I can understand the desire to avoid
 publically shaming people right away, because the accusations may be
 false, or may be arising from a simple mis-understanding, but at some
 point genuine issues like this need to be public. Without this we make
 it difficult for contributors to make an informed decision at future

You got my intention right: I wanted to understand better what lead some
people to create a private channel, what were their needs. For that
objective, having an accusatory tone won't go anywhere and instead I
needed to provide them a safe place to discuss and then I would report
back in the open.

So far, I've only received comments in private from only one person,
concerned about public logging of channels without notification. I
wished the people hanging out on at least one of such private channels
would provide more insights on their choice but so far they have not.

Regarding the why at least one person told me they prefer not to use
official openstack IRC channels because there is no notification if a
channel is being publicly logged. Together with freenode not obfuscating
host names, and eavesdrop logs available to any spammer, one person at
least is concerned that private information may leak. There may also be
legal implications in Europe, under the Data Protection Directive, since
IP addresses and hostnames can be considered sensitive data. Not to
mention the casual dropping of emails or phone numbers in public+logged

I think these points are worth discussing. One easy fix this person
suggests is to make it default that all channels are logged and write a
warning on wiki/IRC page. Another is to make the channel bot announce
whether the channel is logged. Cleaning up the hostname details on
join/parts from eavesdrop and put the logs behind a login (to hide them
from spam harvesters). 



OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] Summit Voting and ATC emails?

2015-02-16 Thread Stefano Maffulli
On Mon, 2015-02-16 at 09:44 +, Daniel P. Berrange wrote:
 Why did we change the rules on summit passes in this way ?

Because there is always a balance to strike between open participation
and effective conversations, while the balance point keeps changing. 

In Paris we've noticed a fairly high participation to the Design
sessions from people who didn't really have anything to contribute to
those sessions. We received quite some complaints about the feeling of
being overcrowded in Paris at the Design session so we thought about
experimenting, like we always do. 

By sending an invite automatically only to the most recent contributors
we're hoping to catch the most involved ones, expecting them to be
contributing more to the sessions. Other invites can be sent to
non-contributors, as we've always done for translators, operators and
users or developers of other projects that PTLs and other leaders
believe would contribute to Design conversations.

We may change the policy again in the future, we'll see how things go in


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] Summit Voting and ATC emails?

2015-02-16 Thread Stefano Maffulli
On Sat, 2015-02-14 at 21:11 -0500, Nick Chase wrote:
 Does anybody know if a) ATC emails have started to go out yet, and b) 
 when proposal voting will start?

Voting started:

Hurry, voting closes at 5pm CT on Monday, February 23. 

Continue to visit for all Summit-related
information, including registration, visa letters, hotels and FAQ. 


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] Summit Voting and ATC emails?

2015-02-15 Thread Stefano Maffulli
On Sun, 2015-02-15 at 14:34 +, Jeremy Stanley wrote:
 Also a reminder, you need to be the owner of a change in Gerrit
 which merged on or after October 16, 2014 (or have an unexpired
 entry in the extra-atcs file within the governance repo) to be in
 the list of people who automatically get complimentary pass

All correct and all explained also here:

The next batch of invites will be sent out after next OpenStack
milestone is released.


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

2015-02-13 Thread Stefano Maffulli
On Thu, 2015-02-12 at 16:01 +, Amrith Kumar wrote:
 How is a private IRC channel any different from a culture of private
 discussions? Having a chat over lunch, in the hallway, on the
 telephone, etc., 

I will articulate again why I think that a group of leaders of OpenStack
*should not* establish a *permanent* private channel for them to hang
out.  This community values openness, all the leaders of this community
are accessible, have open-door policies. This community (call it
'organization' if you prefer) has values and habits, all revolve around
public and accessible discussions. A *permanent* private channel for
OpenStack has nothing to do in this community and should not exist.

The causes for this permanent channel need to be identified and removed.

 Let me be honest with you and say this. If you or someone else can
 show me a good reason why the IRC channel (password protected) that I
 participate in is somehow bad for open communication, I will be happy
 to fix that. 

No, sorry, it has to be the other way around: we've been having IRC
public channels and public conversations for years and we've created one
of the largest, probably the fastest growing open source collaboration
out there. It's up to you to demonstrate why you need a private
*permanent* channel. 

 And so far, no real indication of why IRC is worse than a private
 phone call or a water-cooler conversation on a regular basis. 

Multiple people have explained why already and you're choosing to ignore
their words: permanent private IRC channels are a bad habit that
reinforces a bad, anti-social behavior. When people develop the habit of
hanging out separately from the rest, aristocracies start to emerge.
That's bad for an open and democratic meritocracy like OpenStack.

 Stefano, I agree. Private conversations should be the norm. 

That's not what I wanted to say. I'm saying the exact opposite: Private
conversations should *not* be the norm, even though they happen often
and are necessary, channes for private conversations should be created
ad-hoc when/where needed and destroyed afterwards. 

If we need private conversations so much to justify the creation of an
elitarian place for people to permanently hangout there we have a very
large problem that needs to be fixed.

Why do you need to hang out in private with fellow developers?


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

2015-02-12 Thread Stefano Maffulli
On Thu, 2015-02-12 at 10:37 +0100, Thierry Carrez wrote:
 Right. You can't prevent occasional private discussions and pings, and
 you shouldn't. It's when you encourage and officialize them (by for
 example creating a channel for them) that things start to go bad.

Yes, that's very bad. Private IRC channels are a bad habit that
reinforces a bad, anti-social behavior. And IRC is mostly a habit: I
join tens of channels but I regularly read one or two. Most people I
know have similar habits.

Private conversations are a fact of life but in OpenStack space they
should be the *exception*, created when needed and destroyed after the

I have private conversations all the time: they are about specific
individuals, include sensitive data, legal issues that cannot be
diffused and similar. I create a private channel or a PM for that
conversation only. 

I don't hang out with others in a private channel: that's a very bad
habit. if you have a private channel you hangout there, you'll read that
channel, share jokes on that and will eventually throw in there topics
to discuss that are perfectly safe to discuss publicly. 

Description: This is a digitally signed message part
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

2015-02-12 Thread Stefano Maffulli
On Thu, 2015-02-12 at 10:35 +, Kuvaja, Erno wrote:
 I'm not attacking against having summits, I think the face to face
 time is incredibly valuable for all kind of things. My point was to
 bring up general flaw of the flow between all inclusive decision
 making vs. decided in summit session.

I have the feeling you're assigning too much importance to the
conversations that happen face to face in the summit. Summits are the
apex, the end (or one of the final moments) of conversations that
started months/weeks before the bi-annual event. They're not the place
where an elite shows up, discusses newly revealed topics and decides
without involving anyone else.

With the design summits being the result of longer conversations, there
is very little risk for the relevant people for *that specific*
conversation not to be in the room. For those rare occasions, we have
setup VoIP bridges and other tools to include them in the room, in real
time and have them participate to the decision-making process in full.

I don't accept the thought that everything has to go back to the mailing
list because that would slow us down *even more*. We're trying to keep a
fine balancing act in place here, between speed and execution and
inclusion. If someone has troubles going to the Summit, let's talk and
solve the problems of the individuals because we can't generalize this
issue too much.


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

2015-02-11 Thread Stefano Maffulli
On Wed, 2015-02-11 at 09:32 -0500, Sean Dague wrote:
 Definitely true, to each his/her own. I still consider it unfortunate.
 I've also heard core developers state that they stopped reading the
 mailing list months ago. Which I also find unfortunate.

That's terrible: do you know why they don't read the list anymore? If
you don't know why, could you ask them or (better yet) put me in touch
with them so I can work out a solution for them?


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

2015-02-11 Thread Stefano Maffulli
On Wed, 2015-02-11 at 10:55 +0100, Flavio Percoco wrote:
 This email is dedicated to the openness of our community/project.

It's good to have a reminder every now and then. Thank you Flavio for
caring enough to notice bad patterns and for raising a flag. 

 ## Keep discussions open
 I don't believe there's anything wrong about kicking off some
 discussions in private channels about specs/bugs. I don't believe
 there's anything wrong in having calls to speed up some discussions.
 HOWEVER, I believe it's *completely* wrong to consider those private
 discussions sufficient. 

Well said. Conversations can happen anywhere and any time, but they
should stay in open and accessible channels. Consensus needs to be built
and decisions need to be shared, agreed upon by the community at large
(and mailing lists are the most accessible media we have). 

That said, it's is very hard to generalize and I'd rather deal/solve
specific examples. Sometimes, I'm sure there are episodes when a fast
decision was needed and a limited amount of people had to carry the
burden of responsibility. Life is hard, software development is hard and
general rules sometimes need to be adapted to the reality. Again, too
much generalization here for what I'm confortable with.

Maybe it's worth repeating that I'm personally (and in my role)
available to listen and mediate in cases when communication seems to
happen behind closed doors. If you think something unhealthy is
happening, talk to me (confidentiality assured).

 ## Mailing List vs IRC Channel
 I get it, our mailing list is freaking busy, keeping up with it is
 hard and time consuming and that leads to lots of IRC discussions.

Not sure I agree with the causality but, the facts are those: traffic on
the list and on IRC is very high (although not increasing anymore

 don't think there's anything wrong with that but I believe it's wrong
 to expect *EVERYONE* to be in the IRC channel when those discussions

Email is hard, I have the feeling that the vast majority of people use
bad (they all suck, no joke) email clients. Lots and lots of email is
even worse. Most contributors commit very few patches: the investment
for them to configure their MUA to filter our traffic is too high.

I have added more topics today to the openstack-dev list[3]. Maybe,
besides filtering on the receiving end, we may spend some time
explaining how to use mailman topics? I'll draft something on Ask, it
may help those that have limited interest in OpenStack.

What else can we do to make things better?

 ## Cores are *NOT* special
 At some point, for some reason that is unknown to me, this message
 changed and the feeling of core's being some kind of superheros became
 a thing. It's gotten far enough to the point that I've came to know
 that some projects even have private (flagged with +s), password
 protected, irc channels for core reviewers.

This is seriously disturbing.

If you're one of those core reviewers hanging out on a private channel,
please contact me privately: I'd love to hear from you why we failed as
a community at convincing you that an open channel is the place to be.

No public shaming, please: education first.


[3] thanks to Luigi Toscano for highlighting some missing ones

OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] EOL and Stable Contributions (was Juno is flubber at the gate) [metrics]

2015-02-10 Thread Stefano Maffulli
On Tue, 2015-02-10 at 15:20 +, Kevin Bringard (kevinbri) wrote:
 I've been talking with a few people about this very thing lately, and
 I think much of it is caused by what appears to be our actively
 discouraging people from working on it. Most notably, ATC is only
 being given to folks committing to the current branch

As Jeremy clarified, this is wrong. I edited the answer to be even more

  Secondly, it's difficult to get stack-analytics credit for back
 ports, as the preferred method is to cherry pick the code, and that
 keeps the original author's name. I've personally gotten a few commits
 into stable, but have nothing to show for it in stack-analytics (if
 I'm doing it wrong, I'm happy to be corrected)

First I want to clarify that git history on visualizes commits (merged changes, more
properly) to all branches, not just trunk.

That said, we probably still miss some attribution there because we
count committers only by looking at the author of a change. If
backports are cherry-picked and therefore retain the author then the new
owner is not *counted* as a new contributor.

I highlight that the scope of Activity Board is not to create vanity
charts but only to highlight trends that are useful to understand the
health of the community. It never had any intention to be precise
because 100% precision is hard.

That said, I'm adding the metrics tag because if there is a way to add
owners of back-ports to the count of contributors to OpenStack that'd be

And if we want to improve the number of contributors to stable release,
we may even create a new panel to show such trend.  Do you agree we need
to look in detail, separately to contributors to stable and to trunk
instead of one blob?


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [horizon][keystone] SSO)

2015-02-09 Thread Stefano Maffulli
On Mon, 2015-02-09 at 13:32 +0400, Anton Zemlyanov wrote:
 2) There is no such a thing as OpenStack ID. Should we use Launchpad?
 Facebook login? Twitter?
Actually, there is: :) It supports OpenID and
OAuth, the code is on

It's in use right now for and it's planned
to be adopted by, wiki, storyboard and all other
services that use Launchapd/Ubuntu OpenID with time, over the next

I also know that Dan Radez would appreciate help to make keystone
support out-of-the-box so that can
adopt it too (instead of facebook, as it is now).


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] The API WG mission statement

2015-02-02 Thread Stefano Maffulli
On Fri, 2015-01-30 at 23:05 +, Everett Toews wrote:
 To converge the OpenStack APIs to a consistent and pragmatic RESTful
 design by creating guidelines that the projects should follow. The
 intent is not to create backwards incompatible changes in existing
 APIs, but to have new APIs and future versions of existing APIs

It's looking good already. I think it would be good also to mention the
end-recipients of the consistent and pragmatic RESTful design so that
whoever reads the mission is reminded why that's important. Something

To improve developer experience converging the OpenStack API to
a consistent and pragmatic RESTful design. The working group
creates guidelines that all OpenStack projects should follow,
avoids introducing backwards incompatible changes in existing
APIs and promotes convergence of new APIs and future versions of
existing APIs.

more or less...


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [OpenStack Foundation] Finding people to work on the EC2 API in Nova

2015-01-30 Thread Stefano Maffulli
On Thu, 2015-01-29 at 16:01 -0800, Michael Still wrote:
 However, we got here because no one is maintaining the code in Nova
 for the EC2 API. This is despite repeated calls over the last 18
 months (at least).

I'd love to get to the root cause before we jump to look for solutions.
The story we hear is that EC2 is important and according to the user
survey there are users that seem to be using OpenStack's EC2 code. Nova
developers point out though that the EC2 code is broken and unusable. So
something is out of whack: either user report are more 'wishes' than
usage or the openstack code is not as bad or someone else is feeding
these users good code (that is not in openstack repositories) or
something else.

I would suggest that we start by reaching out to these users. 

Which questions shall we ask them? I'd start from:

* where did you get the EC2 API: vanilla openstack (version, etc) or via
a vendor? which vendor?
* how do you use the EC2 code? Anecdotes are enough I think at this

Tim and user committee: do you think I or Tom can get the list of
respondents to the user survey who declared to use EC2 so we can ask
them more questions?

If not, we can start by asking on the operators list and blog posts and
wait for someone to come forward.

OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all] All rights reserved V.S. Apache license

2015-01-18 Thread Stefano Maffulli
On Sat, 2015-01-17 at 16:07 -0500, Monty Taylor wrote:
 It's actually a set of words that is no longer necessary as of the year
 2000. It's not communicating anything about a granted license, which is
 what the Apache License does - it's actually just asserting that the
 original copyright holder asserts that they have not waived any of their
 rights as a copyright holder. However, the Berne convention grants this
 automatically without a positive assertion.

I think ZhiQiang Fan's question is about the sentence all rights
reserved followed by the implicit some rights not reserved granted by
the Apache license, rather than the meaning of 'all rights reserved'
alone. You're right that such sentence by itself is meaningless but in
the context of the Apache license I think it's confusing at best,
probably wrong.

I don't remember seeing this case discussed on legal-discuss and I'm
quite sure that the right way to apply the Apache license to source code
is *not* by saying (C) `date +%Y` Foo Corp, All Rights Reserved
followed by Apache license (see appendix on

Maybe a passage on legal-discuss would be better?


OpenStack Development Mailing List (not for usage questions)

[openstack-dev] Why all OpenStack Foundation Individual Members should vote now [all]

2015-01-14 Thread Stefano Maffulli
HOW TO VOTE: If you are an eligible voter[1], you should have received
an email with the subject “OpenStack Foundation – 2015 Individual
Director Election” from This email includes
your unique voting link. If you did not receive an email, please contact

If you are an active member of the OpenStack Foundation, you should have
received an email in your inbox with a link to vote for renewal of the
Board of Directors and to change the Foundation’s bylaws. The changes to
the bylaws make this election different from others and require your

During 2014, the OpenStack community created several revisions of the
Bylaws as part of the process to define what makes up core OpenStack
functionality. The proposed revisions to the Bylaws are meant to provide
flexibility in determining the software required for use of the
OpenStack trademarks. The revisions also permit the adoption of the
“DefCore” procedures and any changes to those procedures in the future.
These amendments have already gone through fifteen revisions with
comments from the Technical Committee, DefCore Committee, OpenStack
Foundation management, Legal Affairs Committee and the Board of

Now it’s your turn: the change to the bylaws require that least 25% of
the eligible voters cast a vote. If the quorum is not reached, the
bylaws won’t change and the work of the Foundation will be more

You have a duty to fulfill and it won’t take much of your time. You can
learn more about the amendments
 We need your click to reach the quorum to improve the Foundation.

[1] Eligible voters are individual members of the OpenStack Foundation
who joined the foundation more than 180 days ago.

OpenStack Development Mailing List (not for usage questions)

[openstack-dev] openstack-dev topics now work correctly

2015-01-09 Thread Stefano Maffulli
Dear all,

if you've tried the topics on this mailing list and haven't received
emails, well... we had a problem on our side: the topics were not setup

Luigi Toscano helped isolate the problem and point at the solution[1].
He noticed that only the QA topic was working and that's the only one
defined with a single regular expression, while all the others use
multiple line regexp.

I corrected the regexp as described in the mailman FAQ and tested that
the delivery works correctly. If you want to subscribe only to some
topics now you can. Thanks again to Luigi for the help. 



OpenStack-dev mailing list

Re: [openstack-dev] The scope of OpenStack wiki [all]

2015-01-09 Thread Stefano Maffulli
On Fri, 2015-01-09 at 10:35 +0100, Thierry Carrez wrote:
 One of the issues here is that the wiki also serves as a default
 starting page for all things not on (its main page
 is a list of relevant links). So at the same time we are moving
 authoritative content out of the wiki to more appropriate,
 version-controlled and peer-reviewed sites, we are still relying on the
 wiki as a reference catalog or starting point to find those more
 appropriate sites. That is IMHO what creates the confusion on where the
 authoritative content actually lives.

There is an intention to redesign the Community page maybe this can be used as a
starting point for discovery of governance, specs, infra manual,
contributor docs, etc? 

The wiki may need a new category for 'stackforge' projects but probably
it makes sense to wait until the new programs.yaml and some tags are
set. Eventually we may match those tags in wiki [[Category:]]...
something for the future. 

Between redesigning www/Community and docs/developers(contributors) I'm
quite confident that most personas currently served by the wiki will
have their interests served better elsewhere.

To answer Carol's comment: no content will be pushed out of the wiki
without a proper migration and redirection. We're discussing the scope
of the wiki so that we can communicate more clearly what content should
be expected to be in the wiki and what we should plan on putting
elsewhere (since so much redesigning is going on).

 So we also need to revisit how to make navigation between the various
 web properties of OpenStack more seamless and discoverable, so that we
 don't rely on the wiki starting page for that important role.

Indeed. The new has a better navigation bar, IMHO and
the wiki pages (and mailing list archives and other sites) have been
left behind. It shouldn't be too hard to sync the navigations for the
sites and offer a common to-level path at least.


OpenStack-dev mailing list

Re: [openstack-dev] The scope of OpenStack wiki [all]

2015-01-08 Thread Stefano Maffulli
On Thu, 2015-01-08 at 12:52 -0800, Sean Roberts wrote:
 Thanks for bringing this up Stef. I have found while introducing
 OpenStack fundamentals in the user groups, what seems logical to us,
 the fully OpenStack immersed, is confusing to newcomers. 

Yeah, I'm diving more in the wiki in preparation for a redesign for (which I think should be called
contributor/ in order to avoid collision with
The How_to_contribute page on the wiki is way past its time and needs to
be gutted, too.

 A specific example comes from the How To Contribute wikipage.
 Explaining the corporate CLA and CCLA link was moved to the infra
 manual. It is cleaner presentation of the information for sure. It
 also left the google searchable wiki links hanging. This is the
 primary way most newcomers will look for information.  It wasn't easy
 to find the information once it was brought to my attention it was
 missing. I fixed it up pretty easily after that. 
Indeed, this is something I've experienced myself. Moving content
around, changing processes, etc are things we should all be doing with
care allowing time and constant communication across multiple channels
(and taking care of proper http redirects, when possible, to instruct
web spiders, too).

In order to better map the anchors we had on the wiki, I've suggested to
add a subsection to the developer guide in infra-manual:

so that we can have something more precise for CLA then the general link

I've also moved most of the content from CLA-FAQ into a set of FAQ on
Ask OpenStack, since that site gets lots more hits from search engines:,faq/page:1/


OpenStack-dev mailing list

[openstack-dev] The scope of OpenStack wiki [all]

2015-01-08 Thread Stefano Maffulli
hello folks,

TL;DR Many wiki pages and categories are maintained elsewhere and to
avoid confusion to newcomers we need to agree on a new scope for the
wiki. A suggestion below is to limit its scope to content that doesn't
need/want peer-review and is not hosted elsewhere (no duplication).

The wiki served for many years the purpose of 'poor man CMS' when we
didn't have an easy way to collaboratively create content. So the wiki
ended up hosting pages like 'Getting started with OpenStack', demo
videos, How to contribute, mission, to document our culture / shared
understandings (4 opens, release cycle, use of blueprints, stable branch
policy...), to maintain the list of Programs, meetings/teams, blueprints
and specs, lots of random documentation and more.

Lots of the content originally placed on the wiki was there because
there was no better place. Now that we have more mature content and
processes, these are finding their way out of the wiki like: 


Also, the Introduction to OpenStack is maintained on together with introductory videos and other
basic material. A redesign of and the new portal are making even more wiki pages obsolete.

This makes the wiki very confusing to newcomers and more likely to host
conflicting information.

I would propose to restrict the scope of the wiki to things that
anything that don't need or want to be peer-reviewed. Things like:

  * agendas for meetings, sprints, etc
  * list of etherpads for summits
  * quick prototypes of new programs (mentors, upstream training) before
they find a stable home (which can still be the wiki)

Also, documentation for contributors and users should not be on the
wiki, but on (where it can be found more easily).

If nobody objects, I'll start by proposing a new home page design and
start tagging content that may be moved elsewhere. 


OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-15 Thread Stefano Maffulli
On 12/09/2014 04:11 PM,  by wrote:
[vad] how about the documentation in this case?... bcos it needs some
 place to document (a short desc and a link to vendor page) or list these
 kind of out-of-tree plugins/drivers...  just to make the user aware of
 the availability of such plugins/driers which is compatible with so and
 so openstack release.  
 I checked with the documentation team and according to them, only the
 following plugins/drivers only will get documented...
 1) in-tree plugins/drivers (full documentation) 
 2) third-party plugins/drivers (ie, one implements and follows this new
 proposal, a.k.a partially-in-tree due to the integration module/code)...
 *** no listing/mention about such completely out-of-tree plugins/drivers***

Discoverability of documentation is a serious issue. As I commented on
docs spec [1], I think there are already too many places, mini-sites and
random pages holding information that is relevant to users. We should
make an effort to keep things discoverable, even if not maintained
necessarily by the same, single team.

I think the docs team means that they are not able to guarantee
documentation for third-party *themselves* (and has not been able, too).
The docs team is already overworked as it is now, they can't take on
more responsibilities.

So once Neutron's code will be split, documentation for the users of all
third-party modules should find a good place to live in, indexed and
searchable together where the rest of the docs are. I'm hoping that we
can find a place (ideally under where third-party
documentation can live and be maintained by the teams responsible for
the code, too.




OpenStack-dev mailing list

Re: [openstack-dev] [OpenStack-Infra] [third-party]Time for Additional Meeting for third-party

2014-12-15 Thread Stefano Maffulli
On 12/05/2014 07:08 AM, Kurt Taylor wrote:
 1. Meeting content: Having 2 meetings per week is more than is needed at
 this stage of the working group. There just isn't enough meeting content
 to justify having two meetings every week.

I'd like to discuss this further: the stated objectives of the meetings
are very wide and may allow for more than one slot per week. In
particular I'm seeing the two below as good candidates for 'meet as many
times as possible':

   *  to provide a forum for the curious and for OpenStack programs who
are not yet in this space but may be in the future
   * to encourage questions from third party folks and support the
sourcing of answers

 2. Decisions: Any decision made at one meeting will potentially be
 undone at the next, or at least not fully explained. It will be
 difficult to keep consistent direction with the overall work group.

I think this needs to be clarified for all teams, not just third-party:
I disagree that important decisions should be taken on IRC. IRC is the
place where discussions happen and agreements may form among a group of
people, but ultimately the communication and the actual *decision* needs
to happen on the wider email list channel.

 My proposal was to have only 1 meeting per week at alternating times,

I'm not going to enter into the specific, as I'm sure you're already
aware and weighted the disadvantages of alternating times and multiple
dates. Only I'd ask you to communicate clearly times and objectives on
the team's and meetings wiki pages.

There are now three slots listed:

Mondays at 1500 UTC, chair Anita
Mondays at 1800 UTC, chair (I'm assuming it's Kurt)
Tuesdays at 0800 UTC, chair Anita

I would suggest you to make an effort to split the agenda across the
three slots, if you think it's possible, or assign priority topics from
the stated goals of the meetings so that people will know what to expect
each time.

The objective of the meetings should be to engage more people in
different timezones, while avoiding confusion. Let me know if you need
help editing the pages.

As I mentioned above, probably one way to do this is to make some slots
more focused on engaging newcomers and answering questions, more like
serendipitous mentoring sessions with the less involved, while another
slot could be dedicated to more focused and long term efforts, with more
committed people?


PS let's continue the conversation only on -infra. I'm replying
including -dev only because I think the point 2. Decisions needed to
be clarified for all.

OpenStack-dev mailing list

Re: [openstack-dev] [neutron] Spec reviews this week by the neutron-drivers team

2014-12-12 Thread Stefano Maffulli
I have adapted to Neutron the specs review dashboard prepared by Joe
Gordon for Nova. Check it out below.

Reminder: the deadline to approve kilo specs is this coming Monday, Dec 15.

On 12/09/2014 06:08 AM, Kyle Mestery wrote:
 The neutron-drivers team has started the process of both accepting and
 rejecting specs for Kilo now. If you've submitted a spec, you will soon
 see the spec either approved or land in either the abandoned or -2
 category. We're doing our best to put helpful messages when we do
 abandon or -2 specs, but for more detail, see the neutron-drivers wiki
 page [1]. Also, you can find me on IRC with questions as well.
 OpenStack-dev mailing list

OpenStack Evangelist - Community
Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] People of OpenStack (and their IRC nicks)

2014-12-10 Thread Stefano Maffulli
On 12/10/2014 02:30 AM, Matthew Gilliard wrote:
 So, are we agreed that is
 the authoritative place for IRC lookups? In which case, I'll take the
 old content out of and leave a
 message directing people where to look.

Yes, please, let me know if you need help.

 I don't have the imagination to use anything other than my real name
 on IRC but for people who do, should we try to encourage putting the
 IRC nick in the gerrit name?

That's hard to enforce. A better way to solve this would be to link
directly gerrit IDs to profile URL but I have no idea how
that would work. Gerrit seems only to show full name and email address
as a fly-over, when you hover on the reviewer/owner name in the UI.

OpenStack-dev mailing list

Re: [openstack-dev] [nova] Kilo specs review day

2014-12-10 Thread Stefano Maffulli
On 12/10/2014 01:41 PM, Michael Still wrote:
 at the design summit we said that we would not approve specifications
 after the kilo-1 deadline, which is 18 December. Unfortunately, we’ve
 had a lot of specifications proposed this cycle (166 to my count), and
 haven’t kept up with the review workload.

Great idea, mikal, thanks for raising this topic. I have asked the
Product and Win The Enterprise working groups to help out, too.


OpenStack-dev mailing list

Re: [openstack-dev] People of OpenStack (and their IRC nicks)

2014-12-09 Thread Stefano Maffulli
On 12/09/2014 06:04 AM, Jeremy Stanley wrote:
 We already have a solution for tracking the contributor-IRC
 mapping--add it to your Foundation Member Profile. For example, mine
 is in there already:

I recommend updating the member profile and add IRC
nickname there (and while you're there, update your affiliation history).

There is also a search engine on:


OpenStack-dev mailing list

Re: [openstack-dev] [neutron] Changes to the core team

2014-12-04 Thread Stefano Maffulli
On 12/04/2014 09:24 AM, Anita Kuno wrote:
 I think we move into very dangerous territory if we are equating a core
 review Gerrit permission (it is just a Gerrit permission, if it is
 perceived as anything other than that that is a perception we have
 created ourselves) with value as an OpenStack contributor.

+2 to what Anita is saying.

We're talking about a tick box in gerrit and it's mostly a burden, an

It's also a box that has been proven multiple times to be
bi-directional: sometimes people get to go work on other things, or get
called back in active duty, and reassigned as code janitors.

I haven't read anything but great comments and thank you notes for Bob
and Nati. They're both great developers and have taken good care of
Neutron's code. Once they're ready to get dirty again, it'll take only a
couple of weeks doing reviews to be picked.

Now, if you (and, more importantly, your employer) thinks that being
core reviewer is a honor and your bonus depends on it, contact me
offline to discuss this further.


OpenStack-dev mailing list

Re: [openstack-dev] Board election

2014-11-30 Thread Stefano Maffulli
On 11/30/2014 06:44 AM, Gary Kotton wrote:
 When I log into the site I am unable to nominate people. Any ideas? I
 get: *Your account credentials do not allow you to nominate candidates.**”*

That means that the account you're using is not the account of an
Individual Member of OpenStack Foundation. Only member of the Foundation
can participate in elections.

 Any idea how to address that?

For you and others, the only way to proceed is to file a bug on

so the web team can help out.

if you want to become a Member of the Foundation and since there is no
UI to change an account from simply a registered user of
to  Individual Member) you should provide in the bug report your name
and state I agree to the terms stated on, I want to register as an
Individual Member of the OpenStack Foundation.


OpenStack-dev mailing list

Re: [openstack-dev] [all] A more dynamic wiki, introducing Categories

2014-11-15 Thread Stefano Maffulli
On 11/14/2014 09:11 PM, Jeremy Stanley wrote:
 Categories emerge automatically as you tag pages into them. No
 separate category creation step is required.

True although incomplete. Categories are just pages, like almost
anything in mediawiki, so if you add text [[Category: New_Category]] in
a page, you're one step closer to creating a new category. To complete
the step, you need to actually create the New_Category page, going to and follow the
steps to create a new category.

To nest categories you can add a category page to a 'parent' category
tagging it with [[Category: Parent_Category]]. For example, see the
Category:Programs page, is itself tagged as [[Category:Home]] so that
the page shows the
categories as a navigable tree.

If you don't create the New_Category page, it will end up in the
'wantedCategories' special page:

Convoluted? Yes, I agree but it is what it is.  Probably it's better
though because if you have too many categories it's like having none. I
would suggest to discuss widely the taxonomy before adding/removing items.


OpenStack-dev mailing list

[openstack-dev] [all] A more dynamic wiki, introducing Categories

2014-11-14 Thread Stefano Maffulli
Hello folks

in the past months Shari and I have implemented more chunks of the
taxonomy developed for us by Katherine Cranford (a volunteer expert).
Using categories in the wiki pages can help us create dynamic pages and
keep information more visible, well organized and discoverable.

For example, we had a page listing all Teams. When someone needed to
create a new Team, someone would have to: 1) create a new page for the
team, save, 2) go to the Teams page, edit page adding a link to the new
page, save. Today instead the process looks like this:

 - Create a new page for the new team
 - Add the text [[Category: Teams]] to the rest of the text
 - save

Done. The new page will be automatically shown on

Category pages are just like any other wiki page: they can have text,
images, can be edited, translated etc. And they automatically show the
pages contained in their category. As an example, see how the dynamic
page for Programs

and the 'static' version look like:

I would apply to Programs the same redirect I created for Teams (unless
someone stops me).

Pages generated automatically this way are a huge improvement to
navigation inside the wiki and I suggest you all to get familiar with
the list of Categories shown in a nice tree on:

and read the Taxonomy section in:

As this is a wiki, your help is needed: think about adding pages you
manage to an existing category and when possible consider moving
'static' pages to the newly created dynamic pages.


OpenStack-dev mailing list

Re: [openstack-dev] [all] A more dynamic wiki, introducing Categories

2014-11-14 Thread Stefano Maffulli
On 11/14/2014 02:50 PM, Thierry Carrez wrote:
 In this precise example, I feel like the dynamic page is much less
 usable than the static page, due to the deep hierarchy.

Got it. The current taxonomy is trying to map precisely the hierarchy of
Program-Projects-Teams therefore it keeps the Nova project under Compute.

In fact, the page of Nova is
somewhat mixing aspects of the Compute program with others more related
to the project Nova and the teams. One thing I wanted to do was to
reshuffle content, too, and split larger pages. But since we're going to
move the official list of Programs outside of the wiki (thankfully) we
may need to redesign the taxonomy and keep it leaner.

I'll put more complex changes like this one on hold until the governance
site is live.


OpenStack-dev mailing list

Re: [openstack-dev] TC election by the numbers

2014-11-01 Thread Stefano Maffulli
On 11/01/2014 04:31 PM, Eoghan Glynn wrote:
 So, just to round out this thread, the key questions are:
  * whether a low  declining turnout is a real problem

I'd like to point out that there 580 'regular' contributors at the
moment[1], these are the authors of 95% of the OpenStack code. 506 total
number of voters.

 and, if so:
  * could this have been driven by a weakness in the voting model,
and/or the perception of representative balance in the outcomes

I would suggest to explore another possible cause: are the elections
advertised enough? Is there enough time for developers to understand
also this important part of OpenStack and get involved? Do we use all
possible channels to communicate the elections and their importance?




Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [Infra][all] Synchronizing local Git and Gerrit repositories

2014-10-29 Thread Stefano Maffulli
On 10/29/2014 07:02 AM, Ondrej Wisniewski wrote:
 If I understand correctly, we cannot use the OpenStack community Git
 servers as our central Git repository since developers cannot push to
 them. And we don't want to go through Gerrit and the code review
 procedure just to share a bit of code with somebody else in the team.
 Thus the need for a local mirror.

I have been having similar questions as Dolph. Are you going to Paris by
chance? It'd be great to have a chat in person and understand exactly
your needs.

 Additionally also a local Gerrit server was set up to allow for internal
 code review within the team before submitting anything to the community
 server (which will be
 done eventually). 

As Dolph mentioned, you may be able to use for
that, keeping the patches as Work In Progress (workflow-1): your
developers can all participate in the reviews and mark the change as
'Ready for review' when ready. This will allow you to stay close to
trunk and avoid complex setup on your side. It also allows your
developers to participate more in the 'openstack way' of doing things,
maybe even do some code reviews for other patches while they're on, it's less likely that your team will show up with
a large patch after a long internal conversation.

 This is also helpful in case our Internet connection
 goes down, as we will still be able to follow the complete workflow
 inside the LAN.

Fair enough: how often does your Internet connection drop?


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] FreeBSD host support

2014-10-27 Thread Stefano Maffulli
On 10/27/2014 08:51 AM, Drew Fisher wrote:
 If devstack itself (not CI, but devstack) is a hard requirement for
 integration we need to probably start up a different thread on what the
 best way for other OSes like FreeBSD and Solaris to work around this
 issue.  What should we be looking at?  A compatible devstack clone that
 configures Solaris as a single-host development OpenStack rig?

I doubt devstack itself is a hard requirement for CI since
Windows/Hyper-V testing is done without devstack. I think what mordred
meant was that you need to provide a way like devstack for Infra team to
test things.

To put the thread back in topic, I would assume that the *BSD folks and
Oracle/Solaris would have good amount of overlap in this area.

How about you team up to either provide good patches to devstack to
support the non-linux options (if this is suitable) or develop a new
tool similar in scope to devstack for all BSD-family? Maybe that would
be good for OS X, too :)

Chat in Paris?


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [all] How can we get more feedback from users?

2014-10-24 Thread Stefano Maffulli
Hi Angus,

quite a noble intent, one that requires lots of attempts like this you
have started.

On 10/23/2014 09:32 PM, Angus Salkeld wrote:
 I have felt some grumblings about usability issues with Heat
 and wanted a way that users could come and give us feedback easily (low
 barrier). I started an etherpad
 ( - the
 first win is it is spelt wrong :-O


 We now have some great feedback there in a very short time, most of this
 we should be able to solve.

 This lead me to think, should OpenStack have a more general mechanism
 for users to provide feedback. The idea is this is not for bugs or
 support, but for users to express pain points, requests for features and

One place to start is to pay attention to what happens on the operators
mailing list. Posting this message there would probably help since lots
of users hang out there.

In Paris there will be another operators mini-summit, the fourth IIRC,
one every 3 months more or less (I can't find the details at the moment,
I assume they'll be published soon -- Ideas are being collected on

Another effort to close this 'feedback loop' is the new working group
temporarily named 'influencers' that will meet in Paris for the first

It's great to see lots of efforts going in the same direction. Keep 'em


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [all] How can we get more feedback from users?

2014-10-24 Thread Stefano Maffulli
On 10/23/2014 11:16 PM, Angus Salkeld wrote:
 Thanks for those pointers, we very interested in feedback from
 operators, but
 in this case I am talking more about end users not operators (people
 that actually use our API).
Great! There is a working group being formed also for that.

I would suggest you to put these sessions in your calendar:


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [all][doc] project testing interface

2014-10-24 Thread Stefano Maffulli
On 10/24/2014 03:03 PM, Anne Gentle wrote:
 The git link is the reference, and we're working on publishing those,
 just have to get a URL/home sorted out.

 In the meantime, yes, you can update the wiki page.

Why not delete the wiki altogether? I think stale content on the wiki is 
damaging us and if we're all agreeing that it's better to use rst files in git 
then let's get rid of old content on the wiki, put redirects or warnings on 
those pages.


OpenStack-dev mailing list

Re: [openstack-dev] [api] API Workgroup git repository

2014-10-22 Thread Stefano Maffulli
Hi Chris

On 10/21/2014 11:08 PM, Christopher Yeoh wrote:
 The API Workgroup git repository has been setup and you can access it
Cool, adding it to the repos to watch. 
 There is some content there though not all the proposed guidelines from
 the wiki page are in yet:

I think that as soon as possible the wiki pages should be deleted and 
redirected to wherever the wg will publish the authoritative content. The wiki 
gets lots of traffic from web searches and stale content there really hurts us.

Where is the content going to live?


OpenStack-dev mailing list

Re: [openstack-dev] [Openstack-docs] Contributing to docs without Docbook -- YES you can!

2014-10-03 Thread Stefano Maffulli
hi Nick,

On 09/29/2014 02:06 PM, Nicholas Chase wrote:
 Because we know that the networking documentation needs particular
 attention, we're starting there.  We have a Networking Guide, from which
 we will ultimately pull information to improve the networking section of
 the admin guide.  

I love experiments and I appreciate your effort to improve the
situation. It's not clear to me what the experiment wants to demonstrate
and I'd appreciate more details.

 The preliminary Table of Contents is here: , and the
 instructions for contributing are as follows:

This is cool and I see there is a blueprint also assigned

  1. Pick an existing topic or create a new topic. For new topics, we're
 primarily interested in deployment scenarios.
  2. Develop content (text and/or diagrams) in a format that supports at
 least basic markup (e.g., titles, paragraphs, lists, etc.).
  3. Provide a link to the content (e.g., gist on, wiki page,
 blog post, etc.) under the associated topic.

Points 1-3 seem to be oriented at removing Launchpad from the equation.
Is that all there is? I guess it makes sense to remove obstacles,
although editing the wiki (since it requires a launchpad account anyway)
may not be the best way to track progress and see assignments.

  4. Send e-mail to reviewers

Why not use the docs mailing list or other facilities on
Who is responding to that address?

  5. A writer turns the content into an actual patch, with tracking bug,
 and docs reviewers (and the original author, we would hope) make
 sure it gets reviewed and merged.

This is puzzling: initially I thought that you had some experimental
magic software that would monitor edits to the wiki TOC page, go grab
html content from gist, blog post, etc, transform that into docbook or
something similar and magically create a task on LP for a doc writer to
touch up and send for review.

My understanding is that the Docs team has been using bug reports on
Launchpad to receive contributions and a writer would pick them from the
list, taking care of the transformation to docbook and gerrit workflow.

Point 5. makes the experiment look like the process already in place,
only using a wiki page first (instead of a blueprint first) and a
private email address instead of a public bug tracker.

Have I got it wrong? Can you explain a bit more why this experiment is
not using the existing process? What is the experiment trying to


Ask and answer questions on

OpenStack-dev mailing list

[openstack-dev] Of wiki and contributors docs (was Re: [Nova] [All] API standards working group)

2014-09-25 Thread Stefano Maffulli
On 09/24/2014 09:09 PM, Anne Gentle wrote:
 I think the wiki is a great place to get ideas out while we look for a
 cross-project specs workflow in the meantime. 

The wiki is a great place to store things temporarily until they mature
and find a stable home :)

Speaking of wiki, those of you that follow the recent changes may have
noticed that I've been doing quite a bit of gardening lately in the
Category namespace[1].

The wiki pages have been growing in a fast pace when thinking of a
taxonomy and more structure was not really an option. Given the feedback
I'm getting from people interested in becoming contributors, I think
it's time to give the wiki more shape.

Some time ago, Katherine Cranford (a trained taxonomist) volunteered to
get through the wiki pages and draft a taxonomy for us. Shari Mahrdt, a
recent hire by the Foundation, volunteered a few hours per week to
implement it and I finally took the lead for a project to reorganize
content for developers (as in contributors) community[2].

We have a proposed taxonomy[3] and a first try at implementing it is
visible as a navigable tree on

Shari and I are keeping track of things to do on this etherpad:

We're very early in this project, things may change and we'll need help
from each editor of the wiki. I just wanted to let you know that work is
being done to improve life for new contributors. More details will follow.



Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [Nova] [All] API standards working group

2014-09-24 Thread Stefano Maffulli
On 09/24/2014 10:05 AM, Jay Pipes wrote:
 Whatever it ends up being, it needs to have some teeth to it. Otherwise,
 we're going to end up in the exact same place we're in now, where each
 project does something slightly different.


I think getting started and produce some material to discuss in Paris
would be the first step. Like other teams or WG, a wiki page for the
team with a mission, roadmap, members would be a start.

I would suggest to stay close to the TC and PTLs to get buy-in from
them, increasing the chances of smooth implementations, while getting
constant feedback from downstream consumers of the APIs.


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [TripleO] Set WIP for stale patches?

2014-09-22 Thread Stefano Maffulli
On Fri 19 Sep 2014 09:25:10 AM PDT, Jeremy Stanley wrote:
 Here we'll just have to agree to disagree. I think core reviewers
 hiding behind an automated process so that they don't have to
 confront contributors about stalled/inadequate changes is inherently
 less friendly. Clearly you feel that contributors are less likely to
 be offended if a machine tells them they need to revisit a change
 because it's impersonal and therefore without perceived human

I think that, if done well, having an automated process that nudges 
owners of a patch when needed could be valuable. Having to rely on 
core-reviewers to start a confrontation may also work, but they need to 
be given tools to engage gently and not piss people off. Sometimes 
leaving the hard job to machines is the right thing to do: don't we 
automatically welcome new committers? Why not nudge them if they 

What I don't understand is how hard is to implement the automated 
workflow in newer gerrit and if it's worth pursuing it.


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [metrics] New version of the Activity Board

2014-09-19 Thread Stefano Maffulli
Thank you Daniel, great job.

On 09/17/2014 09:03 AM, Daniel Izquierdo wrote:
 * Further work
 - Add Juno release information

It's coming :)

 - Allow to have projects navigation per release

This is interesting

 - Add Askbot data per release

This is really not needed, don't spend time on it.

 - Add IRC data per release

As above, I don't think it makes sense to aggregate and display chat
data per release.

 - Improve navigation (feedback is more than welcome here).

One comment I collected: The data displayed is aggregated weekly but
that time unit is not displayed anywhere on the charts. Maybe the pop-up
baloons may say 'Week 1 May 2014' or week 1 2014 for the first week of
January 2014?


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [all] OpenStack bootstrapping hour - Friday Sept 19th - 3pm EST

2014-09-15 Thread Stefano Maffulli
On 09/15/2014 03:56 PM, Sean Dague wrote:
 A few of us have decided to pull together a regular (cadence to be
 determined) video series taking on deep dives inside of OpenStack,
 looking at code, explaining why things work that way, and fielding
 questions from anyone interested.
 For lack of a better title, I've declared it OpenStack Bootstrapping Hour.

More than awesomely fantastic job! Let me know all the details asap so I
can help with the promotion.


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [Zaqar] Comments on the concerns arose during the TC meeting

2014-09-10 Thread Stefano Maffulli
On 09/05/2014 12:36 PM, Tim Bell wrote:
 How can the average deployer know whether a stackforge is
 a.  An early prototype which has completed (such as some of the
 early LBaaS packages)
 b.  A project which has lost its initial steam and further
 investment is not foreseen
 c.  A reliable project where there has not been a significant need
 to change recently but is a good long term bet

This pops up often and to me it looks like a software procurement issue,
something that the 'buyer' needs to be able to sort out either with the
help of their vendors (distributions or system integrators), or if they
go DIY, with other instruments to check code quality, level of support
by the community, professional support etc (there are a few EU funded
researches and tools, like

Why do you think any open source project should be in the business of
providing such assurances? Isn't that a role more suitable for the
commercial ecosystem?


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [nova][neutron][cinder] Averting the Nova crisis by splitting out virt drivers

2014-09-10 Thread Stefano Maffulli
On 09/10/2014 02:27 AM, Sylvain Bauza wrote:
 Well, both proposals can be done : we can create subteams and the
 Subteam-Approval Gerrit label right know before Kilo, and we could split
 the virt repos by later once the interfaces and prereqs are done.

That's what I mean in fact: create sub team is fairly easy to do, we can
start very soon. Splitting the repos will require the cleanup in
internal interfaces, documentation and the other things that (while
important and needed anyway) will require probably one cycle, if not more.

On 09/10/2014 09:07 AM, Kyle Mestery wrote:
 I would be cautious around sub-teams. Our experience in Neutron has
 been that we do a very good job of setting up sub-teams, but a
 terrible job at deciding when they should be spun-down and folded back
 in. Because in a lot of cases, a sub-team's existance should be for a
 short period of time. The other problem is that sub-teams can tend to
 wander away from the broader team, making it harder for their work to
 be integrated back into the whole. All of this is to say that
 sub-teams require coordination and lots of communication, and should
 be carefully watched, groomed, and culled when necessary.

This is great feedback. Maybe picking the leaders of the sub-teams based
on their communication skills and their understanding of the bigger
picture would help? How would you do things differently, based on your


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [Zaqar] Comments on the concerns arose during the TC meeting

2014-09-10 Thread Stefano Maffulli
On 09/10/2014 12:56 PM, Monty Taylor wrote:
 I reject soundly and fundamentally the idea that Open Source projects
 NEED a commercial ecosystem to provide solid quality software. 

That's not what I said. I said that assuring the quality of code on a
public repository is not necessarily something that can be asked to the
maintainers of the code. A very simple example: a repository where
nobody committed anything for a long time.  If nobody seems to be
maintaining the code, how can a user get an assurance of the quality of
its code?

That's all I meant to say: quality of open source code (just like
non-free software code) is not necessarily something that can be left to
the maintainers of the code. It's like asking the waiter if the wine is
good... of course the answer is yes.

 That is a description of a thing called Open Core 

So not. Open Core is a different thing and is orthogonal to code
quality, quality and width of support, maintenance etc.

 Apache has been the dominant web server for forever, and if there is any
 human who has ever purchased Commerical Apache they are an absolute

And yet, Red Hat sells quite a lot of software that is completely free
as in beer (in addition to being free as in freedom). This is what I'm
talking about, not 'open core'.

To go back in topic, I was explicitly addressing Tim's question
How can the average deployer know whether a stackforge is [...] and my
answer is that stackforge can have perfectly fine code while there
could be bad code in openstack/*.

And I simply don't think that the openstack project as a whole can
answer anything but all our code is great, if asked. Therefore,
deciding whether code on stackforge or anywhere else for that matter,
needs to be properly evaluated at procurement time.

On 09/10/2014 10:45 AM, Tim Bell wrote:
 There is an impression that open source software does not have
 procurement issues.

I guarantee you I never had that impression, quite the contrary instead.
I've worked with Italian government and large corporations to teach them
how to deal with open source code long since there was no Red Hat in Italy.

Also, to clarify my answer to Tim, I reject the idea that code in
stackforge is a second class citizen. As simple as that.


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [nova][neutron][cinder] Averting the Nova crisis by splitting out virt drivers

2014-09-09 Thread Stefano Maffulli
On 09/09/2014 06:55 AM, James Bottomley wrote:
 CLAs are a well known and documented barrier to casual contributions

I'm not convinced about this statement, at all. And since I think it's
secondary to what we're discussing, I'll leave it as is and go on.

 I've done both ... I do prefer the patch workflow to the gerrit one,

Do you consider yourself a 'committed' developer or a casual one?
Because ultimately I think this is what it comes down to: a developer
who has a commitment to get a patch landed in tree has a different
motivation and set of incentives that make climbing the learning curve
more appealing. A casual contributor is a different persona.

 Bad code is a bit of a pejorative term.

I used the wrong term, I apologize if I offended someone: it wasn't my

 However, I can sympathize with the view: In the Linux Kernel, drivers
 are often the biggest source of coding style and maintenance issues.
 I maintain a driver subsystem and I would have to admit that a lot of
 code that goes into those drivers that wouldn't be of sufficient
 quality to be admitted to the core kernel without a lot more clean up
 and flow changes.

thanks for saying this a lot more nicely than my rough expression.

 To me, this means you don't really want a sin bin where you dump
 drivers and tell them not to come out until they're fit to be
 reviewed by the core; You want a trusted driver community which does
 its own reviews and means the core doesn't have to review them.

I think we're going somewhere here, based on your comment and other's:
we may achieve some result if we empower a new set of people to manage
drivers, keeping them in the same repositories where they are now. This
new set of people may not be the current core reviewers but other with
different skillsets and more capable of understanding the driver's
ecosystem, needs, motivations, etc.

I have the impression this idea has been circling around for a while but
for some reason or another (like lack of capabilities in gerrit and
other reasons) we never tried to implement it. Maybe it's time to think
about an implementation. We have been thinking about mentors, maybe that's a way to go?
Sub-team with +1.5 scoring capabilities?


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [nova][neutron][cinder] Averting the Nova crisis by splitting out virt drivers

2014-09-08 Thread Stefano Maffulli
On 09/05/2014 07:07 PM, James Bottomley wrote:
 Actually, I don't think this analysis is accurate.  Some people are
 simply interested in small aspects of a project.  It's the scratch your
 own itch part of open source.  The thing which makes itch scratchers
 not lone wolfs is the desire to go the extra mile to make what they've
 done useful to the community.  If they never do this, they likely have a
 forked repo with only their changes (and are the epitome of a lone
 wolf).  If you scratch your own itch and make the effort to get it
 upstream, you're assisting the community (even if that's the only piece
 of code you do) and that assistance makes you (at least for a time) part
 of the community.

I'm starting to think that the processes we have implemented are slowing
down (if not preventing) scratch your own itch contributions. The CLA
has been identified as the cause for this but after carefully looking at
our development processes and the documentation, I think that's only one
part of the problem (and maybe not even as big as initially thought).

The gerrit workflow for example is something that requires quite an
investment in time and energy and casual developers (think operators
fixing small bugs in code, or documentation) have little incentive to go
through the learning curve.

To go back in topic, to the proposal to split drivers out of tree, I
think we may want to evaluate other, simpler, paths before we embark in
a huge task which is already quite clear will require more cross-project

From conversations with PTLs and core reviewers I get the impression
that lots of drivers contributions come with bad code. These require a
lot of time and reviewers energy to be cleaned up, causing burn out and
bad feelings on all sides. What if we establish a new 'place' of some
sort where we can send people to improve their code (or dump it without
interfering with core?) Somewhere there may be a workflow
go-improve-over-there where a Community Manager (or mentors or some
other program we may invent) takes over and does what core reviewers
have been trying to do 'on the side'? The advantage is that this way we
don't have to change radically how current teams operate, we may be able
to start this immediately with Kilo. Thoughts?


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [Manila]

2014-09-05 Thread Stefano Maffulli

Hi Jyoti

This is the wrong email list: we use openstack-dev only to discuss 
future development of OpenStack project. Use the General mailing list 
or the one for Operators (check 
Alternatively search for answers (and if you don't find any, ask 
questions) on


OpenStack-dev mailing list

[openstack-dev] DefCore Community Meetings 9/10 9/11 AGENDA (Lighthouse.7)

2014-09-05 Thread Stefano Maffulli
The DefCore project is moving forward and needs more and more eyes on
it. The next meetings are on Sept 9 and 10, with the same agenda to
facilitate global access.

I'm sharing the details below. All members of OpenStack ecosystem should
follow this process closely as it is going to define what an OpenStack
cloud will have to look like before it can be called OpenStack.

Get familiar with Rob Hirschfeld's series on DefCore, starting from


# Agenda

1. Review DefCore status and history
2. Review  Discuss Designated Sections proposal

# Community Meetings about Designated Sections

## Meeting 1 9/10 @ 6 pm PT
* Join the meeting:
* Other international numbers available:

## Meeting 2 9/11 @ 8 am PT

* Join the meeting:
* Other international numbers available:

* By phone:
   - United States - Hartford, CT   +1.860.970.0010
   - United States - Los Angeles, CA   +
   - United States - Thousand Oaks, CA   +1.805.309.5900
   - Access Code   [see meeting]

Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [nova][neutron][cinder] Averting the Nova crisis by splitting out virt drivers

2014-09-04 Thread Stefano Maffulli
Thanks Daniel for taking the time to write such deep message. Obviously
you have thought about this issue for a long time and your opinion comes
from deep personal understanding. I'm adding tags for neutron and
cinder, as I know they're having similar conversations.

I don't have a strong opinion on the solution you and Kyle seem to be
leaning toward, I just have a couple of comments/warnings below

On 09/04/2014 03:24 AM, Daniel P. Berrange wrote:
 saying 'This Is a Large Crisis'. A large crisis requires a large

Not necessarily, quite the contrary indeed. To address and solve big
problems, experience and management literature suggest it's a lot better
to make *one* small change, measure its effect and make one more change,
measure its effect, and on and on until perfection. The discussion
triggered by TripleO about 'what to measure' goes in the right

Your proposal seem to require a long term investment before its effects
can be visible, although some of the things necessary for the split will
be needed anyway. Do you think there are small changes with high impact
that we can refine in Paris and put in place for Juno?

The other comment I have is about the risks of splitting teams and
create new ones whose only expertise is their company's domain. I'm
concerned of the bad side effect of having teams in Nova Program with
very limited or no incentive at all to participate in nova-common
project since all they care about will be their little (proprietary)
hypervisor or network driver. I fear we may end up with nova-common
owned by a handful of people from a couple of companies, limping along,
while nova-drivers devs throw stones or ignore.

Maybe this worst case scenario of disenfranchised membership is not as
bad as I think it would be, I'm voicing my concern also to gauge this
risk better. What are your thoughts on this specific risk? How can we
mitigate it?



OpenStack-dev mailing list

Re: [openstack-dev] [OpenStack-Infra] [third-party] [infra] New mailing lists for third party announcements and account requests

2014-09-02 Thread Stefano Maffulli
On Fri 29 Aug 2014 03:03:34 PM PDT, James E. Blair wrote:
 It's the best way we have right now, until we have time to make it more
 self-service.  We received one third-party CI request in 2 years, then
 we received 88 more in 6 months.  Our current process is built around
 the old conditions.  I don't know if the request list will continue
 indefinitely, but the announce list will.  We definitely need a
 low-volume place to announce changes to third-party CI operators.

Let me make it more clear: I acknowledge your pain and I think that
you're doing a great job at scaling up the efforts. It's great that
there is a team in charge of helping 3rd party CI folks get onboard.
Indeed, there are a lot of administrative requests coming into the infra
list and that is distracting.

NOTE before reading forward: I'm basing my opinion on the URL that
pleia2 shared before; if there have been conversations with the majority
of the 3rd party CI folks where they expressed agreement on the decision
to create 2 new lists, then most of my concerns disappear.

The reason of my concern comes from the way the decision was taken, its
speed and the method. I've seen in other OpenStack programs the bad
effects of important decisions, affecting multiple people, taken too
rapidly and with little socialization around them.

My job is to keep all openstack contributors happy and if all programs
start introducing radical changes with little discussions, my job
becomes almost impossible.

Summing up: I don't question infra's legitimate decision, provoked by a
visible pain in the program. I'm not sure adding more lists is going to
help but I don't want to dive in the choice of the tools: it's the
method that I disagree with because it may confuse new contributors and
makes my job less effective. I wish decisions involving
new/inexperienced contributors be taken by all teams with longer/deeper


Ask and answer questions on

OpenStack-dev mailing list

[openstack-dev] znc as a service (was Re: [nova] Is the BP approval process broken?)

2014-09-02 Thread Stefano Maffulli
On 08/29/2014 11:17 AM, John Garbutt wrote:
 After moving to use ZNC, I find IRC works much better for me now, but
 I am still learning really.

There! this sentence has two very important points worth highlighting:

1- when people say IRC they mean IRC + a hack to overcome its limitation
2- IRC+znc is complex, not many people are used to it

I never used znc, refused to install, secure and maintain yet another
public facing service. For me IRC is: be there when it happens or read
the logs on eavesdrop, if needed.

Recently I found out that there are znc services out there that could
make things simpler but they're not easy to join (at least the couple I
looked at).

Would it make sense to offer znc as a service within the openstack project?

Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [OpenStack-Infra] [third-party] [infra] New mailing lists for third party announcements and account requests

2014-08-29 Thread Stefano Maffulli
On Fri 29 Aug 2014 12:47:00 PM PDT, Elizabeth K. Joseph wrote:

 This list is the new place to request the creation or modification of
 your third party account. Note that old requests sent to the
 openstack-infra mailing list don't need to be resubmitted, they are
 already in the queue for creation.

I'm not happy about this decision: creating new lists is expensive, it
multiplies entry points for newcomers, which need to be explained *and*
understood. We've multiplying processes, rules, points of contact and
places to monitor, be aware of... I feel overwhelmed. I wonder how much
worse that feeling is for people who are not 150% of their time
following discussions online and offline on all OpenStack channels.

Are you sure that a mailing list is the most appropriate way of handling
requests? Aren't bug trackers more appropriate instead?  And don't we
have a bug tracker already?

 It would also be helpful for third party operators to join this
 mailing list as well as the -announce list in order to reply when they
 can to distribute workload and support new participants to thethird
 party community.

What makes you think they will join a list called 'request'? It's a
request: I file a request, get back what I asked for, I say goodbye.
Doesn't sound like a place for discussions.

Also, if the problem with third-party operators is that they don't stick
around, how did you come to the conclusion that two more mailing lists
would solve (or help solving) the problem?

Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [neutron][lbaas][octavia]

2014-08-28 Thread Stefano Maffulli
On 08/28/2014 03:04 PM, Susanne Balle wrote:
 Just for us to learn about the incubator status, here are some of the
 info on incubation:

These are not the correct documents for the Neutron incubator.

You should look at this instead:

(which is modeled after the Oslo incubator


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective

2014-08-27 Thread Stefano Maffulli
On 08/21/2014 03:12 AM, Ihar Hrachyshka wrote:
 I wonder where discussion around the proposal is running. Is it public?

Yes, it's public, and this thread is part of it. Look at the dates of
the wiki: this is a recent proposal (first appearance Aug 11), came out
to address the GBP issue, quickly iterated over a couple of IRC neutron
meetings, and quick phone calls to get early feedback from the GBP team,
Octavia and a few others.

 Though the way incubator is currently described in that proposal on
 the wiki doesn't clearly imply similar benefits for the project, hence

The rationale for the separate repository is that Neutron's code needs a
lot of love for the *existing* codebase, before new features can be
added (and before core team can accept more responsibilities for it).
But progress is unstoppable: new features are being proposed every cycle
and reviewers bandwidth is not infinite.

That's the gist of 'Mission' and 'Why a Seperate Repo?' on

 Of course, we should raise the bar for all the code - already merged,
 in review, and in incubator. I just think there is no reason to make
 those requirements different from general acceptance requirements (do
 we have those formally defined?).

yes, there is a reason to request higher standards for any new code, why
wouldn't there be? If legacy code is struggling to improve test
coverage, there is a very good reason not to accept more debt.

Not sure it's spelled out and where but I believe it's an accepted and
shared best practice among core reviewers not to merge code without tests.


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] What does NASA not using OpenStack mean to OS's future

2014-08-25 Thread Stefano Maffulli
On 08/25/2014 02:36 PM, Joshua Harlow wrote:
 So to see if we can get something useful from this thread.

not on this mailing list. Move it somewhere else: this thread is off
topic here.


OpenStack-dev mailing list

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

2014-08-25 Thread Stefano Maffulli
On Mon 25 Aug 2014 03:38:18 PM CDT, Zane Bitter wrote:
 I'd say we've done fairly well, but I would attribute that at least in
 part to the fact that we've treated the PTL as effectively the
 temporary release management contact more than the guy who will
 resolve disputes for us. In other words, despite rather than because
 of the requirement to have a PTL.

I found this (despite rather than because) a non sequitur.

Let's put this conversation to rest since it seems there is no 
disagreement on the fact that the PTL role is working and stop 
investigating why it's working.

 Imagine a scenario where the community is more or less evenly
 split and neither side is willing to back down even after seeking
 guidance from the TC, the PTL breaks the deadlock by fiat in lieu of
 consensus, followed by [...]

You highlight an interesting scenario: let's file it in the 'risks' 
bucket. I think  we have already ways to mitigate the risk of this 
unlikely event to happen, with Foundation intervening, Board and other 
mediation coming from *outside* of the dev community.

OpenStack-dev mailing list

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

2014-08-25 Thread Stefano Maffulli
On 08/22/2014 08:19 PM, John Dickinson wrote:
 I think Anne makes some excellent points about the pattern being
 proposed being unlikely to be commonly implemented across all the
 programs (or, at best, very difficult). Let's not try to formalize
 another best practice that works many times and force it to work
 every time. 

I kinda agree with John here. I think the most important effect of this
proposal is that it will add *transparency* to the development effort.
One of the most common questions I have to answer is 'Who should I talk
to to address this issue? and I can't blame them. Just to give you an
example, the list of core reviewers of many project is not immediately
available, sometimes even the name of the PTL is missing from their wiki
pages (since the wiki pages don't follow a common template).

Since we've been growing so much I'm not surprised nor afraid of
becoming more of a bureaucratic organization (in Taylor/Weber's sense of
an organizational structure, we're simply growing up --poor wikipedia
page on this topic
and introduce more rules.

I like the idea of having a template of roles that support PTLs in their
job and I think we should let PTLs pick which of the roles to fill in,
but not divert too much from the common list of roles. And we need to
make sure that these roles and people are communicated properly.

I think we outgrew the phase where any PTL could experiment and
self-organize in full autonomy because snowflakes are too hard to manage
and produce only entropy at our size. We have too many projects,
programs and teams and if all of them operate very differently it
becomes next to impossible for newcomers to join. It gets too hard even
for community  managers to advice newcomers. We're too big for that.
Some level of standardization is inevitable :)

 And let's get the PTLs
 together for one or two days every cycle to discuss project issues.
 Just PTLs, and let's focus on the project management stuff and some
 cross-project issues.

This is orthogonal to the PTLs supporting roles: we can sure do
something to help in this aspect.

On another note, bike shed 'czar' gets -1 from me. Liaison or any of
fungi's suggestions sound better :)


OpenStack-dev mailing list

Re: [openstack-dev] [Octavia] IRC meetings

2014-08-21 Thread Stefano Maffulli
On 08/21/2014 10:14 AM, Doug Wiegley wrote:
 We made the voice/IRC decision in the very format that favors voice.  So
 in the interest of putting the discussion to bed, voice your opinions here
 in a non-voice way:

I was about to voice (ha!) my opinion there but I stopped because I
don't think we should have that conversation to start with. Audio calls
are ok for a lot of things but if we're talking about enabling an open
collaboration then there is one rule to follow:

 - provide a URL with indexed, searchable text or it didn't happen

My vote goes for the Octavia team to provide just that. If you have a
way to do that with webex, hangout, anything fancy, use them. If not,
consider revert to the minimum common denominator.


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] New feature on Nova

2014-08-21 Thread Stefano Maffulli
On 08/21/2014 08:00 AM, wrote:
 Sorry if I am not on the right mailing list. I would like to get some

No problem, this is the correct mailing list as this message is about
discussing the future of an openstack component.

 I would like to know if I am a company who wants to add a feature on an
 openstack module. How do we have to proceed ? And so, what is the way
 this new feature be adopted by the community.

This message is a good way to start: circulate the idea and start
collecting feedback from other developers. As Daniel P. Berrange said,
you may need to file a spec and blueprint later on if you get positive
feedback. Jay's message makes me think that your proposal may need more
discussion on this list, maybe on IRC too, before you embark in
proposing a spec+blueprint.

A small and important note: companies are not people (despite what US
Supreme Court thinks), so a new feature is proposed by people. People
propose new features and discuss them, defend them, develop them, review
them, etc. Companies give money in exchange. It's a crucial distinction.


 This message and its attachments may contain confidential or privileged 
 information that may be protected by law;
 they should not be distributed, used or copied without authorisation.
 If you have received this email in error, please notify the sender and delete 
 this message and its attachments.
 As emails may be altered, Orange is not liable for messages that have been 
 modified, changed or falsified.
 Thank you.

Bah. This message was sent to a public mailing list. If it contains
confidential information, tough for Orange: it's gone, public, used,
copied and distributed. The receivers cannot be held accountable. These
automatic messages are so useless.

Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [all] The future of the integrated release

2014-08-21 Thread Stefano Maffulli
I think we can't throw Ceilometer and Triple-O in the same discussion:
they're two separate issues IMHO, with different root causes and
therefore different solutions.

On 08/21/2014 06:27 AM, Jay Pipes wrote:
 The point I've been making is
 that by the TC continuing to bless only the Ceilometer project as the
 OpenStack Way of Metering, I think we do a disservice to our users by
 picking a winner in a space that is clearly still unsettled.

When Ceilometer started there was nothing in that area. A quite
significant team formed to discuss API and implementation for metering
OpenStack. All was done in the public and getting as many people
involved from the start. Ceilometer was integrated because the whole
OpenStack project has been about fostering collaboration *on top* of a
common technical infrastructure. And because it was considered ready
from the technical aspect.

Now we're finding out that we don't have appropriate processes and tools
to evaluate what happens later in the maturating cycle of technology:
Ceilometer is not considered the only nor the best tool in town
anymore. How to deal with this?

Your proposal seem to go towards the old, known, 20 years old territory:
OpenStack should provides infrastructure and some mentorship to
development teams, and that's it. That's somewhere between SourceForge
and Apache Foundation.

Contrary to other open source foundations, we have put in places
processes and tools to pick our favorite projects based not just on
technical merits. We're giving strong incentives to do open
collaboration. The collaboration across large corporations as put in
place in OpenStack doesn't happen by chance, quite the contrary.

This is what makes OpenStack different (and probably one of its main
reasons for success).

 Specifically for Triple-O, by making the Deployment program == Triple-O,
 the TC has picked the disk-image-based deployment of an undercloud
 design as The OpenStack Way of Deployment. 

Triple-O is a different case, as puppet and chef modules have existed
since I can remember and OOO is only one of many. Different problem that
should be discussed at TC level. A lot of improvements can be imagined
for the Deployment program.

 I believe by picking winners in unsettled spaces, we add more to the
 confusion of users than having 1 option for doing something.

I think this conversation is crossing the very important What is
OpenStack? issue. Most likely the answer won't be as clear cut as
OpenStack is what the TC decides is integrated. A lot of your concerns
about the TC 'picking the winner' will be resolved because it won't be
the TC alone to decide what will be using the OpenStack mark.


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] generate Windows exe

2014-08-20 Thread Stefano Maffulli
Hi Szepe,

On Wed 20 Aug 2014 11:33:47 AM PDT, Szépe Viktor wrote:
 Thank you for your answer.
 That workflow seems a huge job for me.

 I leave this patch up to you.

thanks for sending this fix. You've stumbled upon one of the known
issues of OpenStack's way to deal with small patches like yours. We have
a workflow optimized for the extremely large amount of patches we get
(around 60-70 *per hour*). Our workflow does not use github and its pull

Unfortunately this optimization for large scale contributions is leaving
occasional contributors like you outside.

I would suggest you to file a bug on instead of a pull request
as we don't use github at all, only drop there code as 'mirror' and
nothing else.

I'll suggest also to add 'file a bug' as a suggestion to the message
sent upon automatically closing the PR.

Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [Octavia] Minutes from 8/13/2014 meeting

2014-08-19 Thread Stefano Maffulli
Thanks for the summary Trevor.

On 08/18/2014 01:25 PM, Trevor Vardeman wrote:
 1) Discuss future of Octavia in light of Neutron-incubator project proposal.
 a) There are many problems with Neutron-Incubator as currently described

Let's be specific, enumerate the problems and address them, please.

And keeping in mind that Neutron code is *still* bashed by many users
out there. In the past user surveys users have asked to 'fix Neutron'
first, not many have asked 'more Neutron'. Here are some actual quotes
from the survey as a reminder:

Would love to see Neutron stabilize (so we can get rid of Nova
networking) and Heat to get moved forward.

More stability / reliability in Neutron. Also, support for Cisco Insieme. 

Neutron is relatively unusable. It's missing quite a bit of
functionality from nova-network that makes it easily usable by small to
medium deployments. 

Get a way from migrating from nova-network multihost to neutron. Giving
priority to bugs that actually affect production installations[...]

I'm sure we'll collect more feedback at the coming Operators Summit,
too. If you're developing Neutron, think about hopping by

 b) The political happenings in Neutron 

This is not the first time I hear about the term 'political' referred to
discussions and decisions that should be technical inside OpenStack.
Being Italian, I take the term 'political' in this context as an offense
since it carries connotations of abuse of power, incompetence, even
straight delinquency.

I'd like to get to the root cause here: OpenStack has places where you
can spell things out without fear of repercussions and people willing to

What are these 'political happenings' that you see? Write or call me,
Tom, call Jonathan Bryce, Heidi Bretz or anybody else at the
Foundation...  We're all available to listen and maintain anonymity. I
(and others at the Foundation) need to understand exactly what is
causing troubles so we can fix them.  Generic allegations don't help.

 b) One major point was other openstack/stackforge use video meetings
 as their primary source as well

What other openstack/ (*not* stackforge) program uses video meetings?


Ask and answer questions on

OpenStack-dev mailing list

[openstack-dev] Network/Incubator proposal (was Re: [Octavia] Minutes from 8/13/2014 meeting)

2014-08-19 Thread Stefano Maffulli
On 08/19/2014 08:39 AM, Eichberger, German wrote:
 Just to be clear: We all think the incubator is a great idea and if
 some things are ironed out will be a good way to onboard new projects
 to Neutron. What bothers me is the timing. Without warning we were
 put in an incubator in the span of like 8 days. 

No, not without warning: 8 days and we're still discussing the solution
for code that has been developed by sub-teams and for which the core
team has not reached consensus whether to merge it or not. As a
reminder, until we started this discussion, the alternative for 'lack of
consensus 3 days before feature freeze' was to leave code out of the
tree. We've done it that way in the past.

Incubator is a *proposal* to improve the situation, provide a way for
code that is considered mature by a sub-team to be shipped to customers
from a repository (as opposed from somewhere else, as
it happened in the past).

The full details are on this wiki page:

 This makes it
 difficult to plan and adds unnecessary uncertainty. Who is
 guaranteeing that if I tell my management LBaaS v2 will be in Kilo
 that nobody will throw a wrench in five months time?

Great question! There is no simple answer: it's a risk everyone involved
in OpenStack decides to run because that risk of a last minute wrench is
balanced by the benefits of getting back a full working engine and spare
parts, with manuals.

That said, there are a lot of ways to mitigate that risk in any case.
One is to pay attention to the priorities set by the project leaders and
help them, first.

Us, the people on this list, should be the ones explaining our managers
what this OpenStack collaboration is all about. If it's not clear to you
how, come to the Upstream Training sessions in Paris to get some ideas.

 What I like to see from the Neutron Core team is timely communication
 with proper transition plans: For example if there is a change in how
 things are done it should be implemented at the beginning of a cycle
 and projects started before the change should have a grace period
 where things are done the old way. I understand that some things
 might have to be retroactively but that should be kept to a minimum -

Yep, this is a very reasonable request. I think the that Neutron Core
Team (and other teams, too) has space for improvements in the way they
communicate to sub-teams and to the Foundation.

This change comes too close to the end of the cycle, I agree and I think
I understand the pain you're going through: it's bad. The only reason
why I support this effort to change *now* is that the alternative to a
new repository with LBaaSv2 code is more likely to be a 'no, come back
for Kilo' (based on past experience). I find the 'no' to be unacceptable
and 'yes' very unlikely. Incubator sounds like a good compromise.

I'd focus our energies to addressing the shortcomings of the Incubator
proposal. I, to start, would advocate for calling this repository
'Labs', a place where cool and interesting things are given a chance to
be tried out and if they stick, users like them, moved to a more
permanent home (or die). Incubator sound too much like something that
needs maturing and it may not be the case (plus it sounds too
burocratic, with rules to graduation, etc).

The sooner we iron out the wrinkles in the proposal the sooner we start
educating distributions that there is good code in there that they may
want to package and ship to users.


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [all] The future of the integrated release

2014-08-19 Thread Stefano Maffulli
On 08/19/2014 07:37 AM, Jay Pipes wrote:
 All of these projects should be able to live in the Program, in the
 openstack/ code namespace, for as long as the project is actively
 developed, and let the contributor communities in these competing
 projects *naturally* work to do any of the following:
  * Pick a best-of-breed implementation from the projects that address
 the same Thing
  * Combine code and efforts to merge the good bits of multiple projects
 into one
  * Let multiple valid choices of implementation live in the same Program
 with none of them being blessed by the TC to be part of the integrated

Sounds reasonable and I'd like to analyze the risks associated with this
change. What's the worst that can happen?

The current setup gives a strong incentive to different teams to
reconcile competing implementations into one collaborative effort (the
Open Development promise[1]): the graduation process is as much about
quality of the code as it is about bootstrapping a culture of
collaboration, not one of competition.

One worst case I see is that we end up with lots of small projects doing
similar/overlapping things or in general not talking much to each other
except to get some infrastructure. (Then we'd have reimplemented the
Apache Foundation).

It's a fine line to walk on. What we have has its big drawbacks, as
Sandy Walsh recently illustrated re:StackTach, and it is definitely in
needs of constant tweaks.



Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] [all] The future of the integrated release

2014-08-13 Thread Stefano Maffulli
On 08/13/2014 07:33 AM, Ian Wells wrote:
 I have no great answer to this, but is there a way - perhaps via team
 sponsorship from cores to ensure that the general direction is right,
 and cloned repositories for purpose-specific changes, as one example -
 that we can get an audience of people to check, try and test proposed
 changes long before they need reviewing for final inclusion?

We (OpenStack project as a whole) have a few ways to  develop and offer
'new' things to others for experiment, fiddle, even ship to customers.

There is stackforge, a place where new code is already being tested,
proposed, incubated, what-have-you. Example: the AWS EC2 and GCE API
compatibility, Congress, Manila, Murano, Gnocchi...

There are incubator repositories, think Oslo-incubator, that regularly
have new things tested and spun-off.

There is also the option of out-of-openstack repositories, like Swift3
for a long time.

Unfortunately we have *a lot* of incentives for code to be in-tree and
integrated, so many of these options carry a stigma, they're
second-class options. I think we may want to review the incentives we've
put as some of them may have already served their purpose and probably
time has come for them to be removed/transformed. A topic for another


Ask and answer questions on

OpenStack-dev mailing list

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-13 Thread Stefano Maffulli
On 08/12/2014 06:46 PM, Wuhongning wrote:
 I couldn't have been at the IRC meeting for the time difference, are
 there any conclusion for this topic, or is it still open?

I, the PTL, some core reviewers and many in the GBP team are actively
working on a proposal to send to the list for quick evaluation. Stay tuned.

 I've tried
 to collect main concerns from previous posts (if something is lost or
 mistaken, just let me know):
 Concern 1 [...] Concern 6 [...]

These are some of the concerns I saw, too. There are other, once you
start looking at this discussion as one touching the larger issue of how
we can, as a community, strike an acceptable balance between shipping
quality code while adding features, keeping the fast innovation pace.

 Is it an option to split the GBP into core and extension, to easily
 meet all those concerns? 

I think these are all valid suggestions and they are in similar forms on
the table at the moment as options.

The solution we're looking for is not something that is limited to GBP
but a wider fix (or at least a reasonable attempt) to the balancing act
I mentioned above: new features vs 'stable' code. Expect a proposal soon.


Ask and answer questions on

OpenStack-dev mailing list

  1   2   >