[openstack-dev] Vancouver Summit CFP is open - what’s new

[Lauren Sell]

Hi everyone,

Today, we opened the Call for Presentations 
 for 
the Vancouver Summit , which 
will take place May 21-24. The deadline to submit your proposal is February 8th.

What’s New?
We’re focused on open infrastructure integration. The Summit has evolved over 
the years to cover more than just OpenStack, but we’re making an even bigger 
effort to attract speakers across the open infrastructure ecosystem. In 
addition to OpenStack-related sessions, we’ll be featuring the newest project 
at the Foundation -- Kata Containers -- as well as recruiting many others from 
projects like Ansible, Ceph, Kubernetes, ONAP and many more.

We’ve also organized Tracks around specific problem domains. We encourage you 
to submit proposals covering OpenStack and the “open infrastructure” tools 
you’re using, as well as the integration work needed to address these problem 
domains. We also encourage you to invite peers from other open source 
communities to come speak and collaborate. 

The Tracks are:

CI/CD 
Container Infrastructure 
Edge Computing
HPC / GPU / AI
Open Source Community
Private & Hybrid Cloud 
Public Cloud 
Telecom & NFV

Where previously we had Track Chairs, we now have Programming Committees 

 for each Track, made up of both Members and a Chair (or co-chairs). We’re also 
recruiting members and chairs from many different open source communities 
working in open infrastructure, in addition to the many familiar faces in the 
OpenStack community who will lead the effort. If you’re interested in 
nominating yourself or someone else to be a member of the Summit Programming 
Committee for a specific Track, please fill out the nomination form 
.
 Nominations will close on January 26, 2018.

Again, the deadline to submit proposals 
 is 
February 8, 2018. Please note topic submissions for the OpenStack Forum 
(planning/working sessions with OpenStack devs and operators) will open at a 
later date.

We can’t wait to see you in Vancouver! We’re working hard to make it the best 
Summit yet, and look forward to bringing together different open infrastructure 
communities to solve these hard problems together! 

Want to provide feedback on this process? Please focus discussion on the 
openstack-community mailing list, or contact me or the OpenStack Foundation 
Summit Team directly at sum...@openstack.org.

Thank you,
Lauren





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

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

[Lauren Sell]

Several folks on this thread have talked about the different constituencies and 
problems we’re trying to solve with naming. Most of the people following this 
thread understand all of the terminology and governance we’ve defined, but 
that's still a very small percentage of people who care about OpenStack at the 
end of the day. I think we’re trying to communicate to the 99% who have 
relatively low context: potential users, people in other open source 
communities, managers at vendor companies, press/analysts, etc. who really want 
to know what we’re doing, but feel overwhelmed and need a simple structure 
interpret it.

Two things we should address:

1) Make it more clear which projects are “officially” part of OpenStack. It’s 
possible to find that information, but it’s not obvious. I am one of the people 
who laments the demise of stackforge…it was very clear that stackforge projects 
were not official, but part of the OpenStack ecosystem. I wish it could be 
resurrected, but I know that’s impractical. 

To make this actionable...Github is just a mirror of our repositories, but for 
better or worse it's the way most people in the world explore software. If you 
look at OpenStack on Github now, it’s impossible to tell which projects are 
official. Maybe we could help by better curating the Github projects (pinning 
some of the top projects, using the new new topics feature to put tags like 
openstack-official or openstack-unofficial, coming up with more standard 
descriptions or naming, etc.). Same goes for our repos…if there’s a way we 
could differentiate between official and unofficial projects on this page it 
would be really useful: https://git.openstack.org/cgit/openstack/

2) Create a simple structure within the official set of projects to provide 
focus and a place to get started. The challenge (again to our success, and lots 
of great work by the community) is that even the official project set is too 
big for most people to follow. 

While I fully admit it was an imperfect system, the three tier delineation of 
“integrated," “incubated" and “stackforge" was something folks could follow 
pretty easily. The tagging and mapping is valuable and provides additional 
detail, but having the three clear buckets is ideal.  I would like to see us 
adopt a similar system, even if the names change (i.e. core infrastructure 
services, optional services, stackforge). Happy to throw out ideas if there is 
interest.

Thanks,
Lauren


> On Jun 21, 2017, at 11:42 AM, Chris Hoge  wrote:
> 
> 
>> On Jun 21, 2017, at 9:20 AM, Clark Boylan > > wrote:
>> 
>> On Wed, Jun 21, 2017, at 08:48 AM, Dmitry Tantsur wrote:
>>> On 06/19/2017 05:42 PM, Chris Hoge wrote:
 
 
> On Jun 15, 2017, at 5:57 AM, Thierry Carrez  > wrote:
> 
> Sean Dague wrote:
>> [...]
>> I think those are all fine. The other term that popped into my head was
>> "Friends of OpenStack" as a way to describe the openstack-hosted efforts
>> that aren't official projects. It may be too informal, but I do think
>> the OpenStack-Hosted vs. OpenStack might still mix up in people's head.
> 
> My original thinking was to call them "hosted projects" or "host
> projects", but then it felt a bit incomplete. I kinda like the "Friends
> of OpenStack" name, although it seems to imply some kind of vetting that
> we don't actually do.
 
 Why not bring back the name Stackforge and apply that
 to unofficial projects? It’s short, descriptive, and unambiguous.
>>> 
>>> Just keep in mind that people always looked at stackforge projects as
>>> "immature 
>>> experimental projects". I remember getting questions "when is
>>> ironic-inspector 
>>> going to become a real project" because of our stackforge prefix back
>>> then, even 
>>> though it was already used in production.
>> 
>> A few days ago I suggested a variant of Thierry's suggestion below. Get
>> rid of the 'openstack' prefix entirely for hosting and use stackforge
>> for everything. Then officially governed OpenStack projects are hosted
>> just like any other project within infra under the stackforge (or Opium)
>> name. The problem with the current "flat" namespace is that OpenStack
>> means something specific and we have overloaded it for hosting. But we
>> could flip that upside down and host OpenStack within a different flat
>> namespace that represented "project hosting using OpenStack infra
>> tooling”.
> 
> I dunno. I understand that it’s extra work to have two namespaces,
> but it sends a clear message. Approved TC, UC, and Board projects
> remain under openstack, and unofficial move to a name that is not
> openstack (i.e. stackforge/opium/etc).
> 
> As part of a branding exercise, it creates a clear, easy to
> understand, and explain division.
> 
> For names like stackforge being considered a pejorative, 

[openstack-dev] Affected by OSIC, Layoffs? Or want to help?

[Lauren Sell]

Hi everyone,

The Foundation wants to help any Stackers affected by recent layoffs such as 
OSIC get to the Boston Summit. There are companies hiring and we want to retain 
our important community members! 

If you are a contributor who was recently laid off and need help getting to 
Boston, please contact me ASAP. We have a little bit of room left in our travel 
support block, and want to extend rooms and free passes to those affected to 
help if we can.  

Amy Marrich also had a great idea for any of you frequent flyers interested in 
pitching in! Community members could offer up some of our personal frequent 
flyer miles to sponsor flights for these Stackers. I’d love to be the 
first...if you were laid off and need sponsorship for a flight, I’m willing to 
sponsor a round trip domestic flight or one-way international flight with my 
miles. Contact me. 

Anyone else want to pitch in?

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

Re: [openstack-dev] Project Navigator Updates - Feedback Request

[Lauren Sell]

Hi Matt,

Thanks for the feedback. 

> On Mar 24, 2017, at 3:50 PM, Matt Riedemann  wrote:
> 
> Overall I like the groupings of the projects in the main page. When I drill 
> into Nova, a couple of things:
> 
> 1. The link for the install guide goes to the home page for docs.o.o rather 
> than https://docs.openstack.org/project-install-guide/ocata/ 
>  - is that 
> intentional?

Good point. We’ll directly the link to the install guide and also change the 
wording in the project details to something along the lines of “Nova is 
included in the install guide” since it’s not linking directly to the 
project-specific install guide.
> 
> 2. The "API Version History" section in the bottom right says:
> 
> "Version v2.1 (Ocata) - LATEST RELEASE"
> 
> And links to https://releases.openstack.org/ 
> . The latest compute microversion in Ocata 
> was actually 2.42:
> 
> https://docs.openstack.org/developer/nova/api_microversion_history.html 
> 
> 
> I'm wondering how we can better sort that out. I guess "API Version History" 
> in the navigator is meant more for major versions and wasn't intended to 
> handle microversions? That seems like something that should be dealt with at 
> some point as more and more projects are moving to using micro versions.

Agreed, we could use some guidance here. From what we can tell, each team logs 
these a little bit differently, so there’s no easy way for us to pull them. 
Could we output the correct link as a tag for each project, or does anyone have 
a recommendation?

Thanks!

> -- 
> 
> Thanks,
> 
> Matt

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

Re: [openstack-dev] Project Navigator Updates - Feedback Request

[Lauren Sell]

Yes, definitely. We’ve started updating the sample configs with web apps and 
big data (primarily driven by the Enterprise Working Group and Kathy Cacciatore 
on the Foundation team) and are about to publish eCommerce. We could pull down 
HTC or some of the other outdated ones for now until we’re able to update them. 


> On Mar 24, 2017, at 12:08 PM, Tim Bell <tim.b...@cern.ch> wrote:
> 
> Lauren,
>  
> Can we also update the sample configurations? We should certainly have 
> Neutron now in the HTC (since nova-network deprecation)
>  
> Tim
>  
> From: Lauren Sell <lau...@openstack.org <mailto:lau...@openstack.org>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org>>
> Date: Friday, 24 March 2017 at 17:57
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org>>
> Subject: [openstack-dev] Project Navigator Updates - Feedback Request
>  
> Hi everyone, 
>  
> We’ve been talking for some time about updating the project navigator, and we 
> have a draft ready to share for community feedback before we launch and 
> publicize it. One of the big goals coming out of the joint TC/UC/Board 
> meeting a few weeks ago[1] was to help better communicate ‘what is 
> openstack?’ and this is one step in that direction.
> 
> A few goals in mind for the redesign:
> - Represent all official, user-facing projects and deployment services in the 
> navigator
> - Better categorize the projects by function in a way that makes sense to 
> prospective users (this may evolve over time as we work on mapping the 
> OpenStack landscape)
> - Help users understand which projects are mature and stable vs emerging
> - Highlight popular project sets and sample configurations based on different 
> use cases to help users get started
> 
> For a bit of context, we’re working to give each OpenStack official project a 
> stronger platform as we think of OpenStack as a framework of composable 
> infrastructure services that can be used individually or together as a 
> powerful system. This includes the project mascots (so we in effect have 
> logos to promote each component separately), updates to the project 
> navigator, and bringing back the “project updates” track at the Summit to 
> give each PTL/core team a chance to provide an update on their project 
> roadmap (to be recorded and promoted in the project navigator among other 
> places!). 
> 
> We want your feedback on the project navigator v2 before it launches. Please 
> take a look at the current version on the staging site and provide feedback 
> on this thread.
> 
> http://devbranch.openstack.org/software/project-navigator/ 
> <http://devbranch.openstack.org/software/project-navigator/>
> 
> Please review the overall concept and the data and description for your 
> project specifically. The data is primarily pulled from TC tags[2] and Ops 
> tags[3]. You’ll notice some projects have more information available than 
> others for various reasons. That’s one reason we decided to downplay the 
> maturity metric for now and the data on some pages is hidden. If you think 
> your project is missing data, please check out the repositories and submit 
> changes or again respond to this thread.
> 
> Also know this will continue to evolve and we are open to feedback. As I 
> mentioned, a team that formed at the joint strategy session a few weeks ago 
> is tackling how we map OpenStack projects, which may be reflected in the 
> categories. And I suspect we’ll continue to build out additional tags and 
> better data sources to be incorporated.
> 
> Thanks for your feedback and help.
> 
> Best,
> Lauren
> 
> [1] 
> http://superuser.openstack.org/articles/community-leadership-charts-course-openstack/
>  
> <http://superuser.openstack.org/articles/community-leadership-charts-course-openstack/>
> [2] https://governance.openstack.org/tc/reference/tags/ 
> <https://governance.openstack.org/tc/reference/tags/>
> [3] https://wiki.openstack.org/wiki/Operations/Tags 
> <https://wiki.openstack.org/wiki/Operations/Tags>
>  
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>

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

[openstack-dev] Project Navigator Updates - Feedback Request

[Lauren Sell]

Hi everyone,

We’ve been talking for some time about updating the project navigator, and we 
have a draft ready to share for community feedback before we launch and 
publicize it. One of the big goals coming out of the joint TC/UC/Board meeting 
a few weeks ago[1] was to help better communicate ‘what is openstack?’ and this 
is one step in that direction.

A few goals in mind for the redesign:
- Represent all official, user-facing projects and deployment services in the 
navigator
- Better categorize the projects by function in a way that makes sense to 
prospective users (this may evolve over time as we work on mapping the 
OpenStack landscape)
- Help users understand which projects are mature and stable vs emerging
- Highlight popular project sets and sample configurations based on different 
use cases to help users get started

For a bit of context, we’re working to give each OpenStack official project a 
stronger platform as we think of OpenStack as a framework of composable 
infrastructure services that can be used individually or together as a powerful 
system. This includes the project mascots (so we in effect have logos to 
promote each component separately), updates to the project navigator, and 
bringing back the “project updates” track at the Summit to give each PTL/core 
team a chance to provide an update on their project roadmap (to be recorded and 
promoted in the project navigator among other places!). 

We want your feedback on the project navigator v2 before it launches. Please 
take a look at the current version on the staging site and provide feedback on 
this thread.

http://devbranch.openstack.org/software/project-navigator/ 


Please review the overall concept and the data and description for your project 
specifically. The data is primarily pulled from TC tags[2] and Ops tags[3]. 
You’ll notice some projects have more information available than others for 
various reasons. That’s one reason we decided to downplay the maturity metric 
for now and the data on some pages is hidden. If you think your project is 
missing data, please check out the repositories and submit changes or again 
respond to this thread.

Also know this will continue to evolve and we are open to feedback. As I 
mentioned, a team that formed at the joint strategy session a few weeks ago is 
tackling how we map OpenStack projects, which may be reflected in the 
categories. And I suspect we’ll continue to build out additional tags and 
better data sources to be incorporated.

Thanks for your feedback and help.

Best,
Lauren

[1] 
http://superuser.openstack.org/articles/community-leadership-charts-course-openstack/
 

[2] https://governance.openstack.org/tc/reference/tags/ 

[3] https://wiki.openstack.org/wiki/Operations/Tags 


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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Lauren Sell]

> On Feb 22, 2016, at 8:52 AM, Clayton O'Neill  wrote:
> 
> I think this is a great proposal, but like Matt I’m curious how it
> might impact the operator sessions that have been part of the Design
> Summit and the Operators Mid-Cycle.
> 
> As an operator I got a lot out of the cross-project designs sessions
> in Tokyo, but they were scheduled at the same time as the Operator
> sessions.  On the other hand, the work sessions clearly aren’t as
> useful to me.  It would be nice would be worked out so that the new
> design summit replacement was in the same location, and scheduled so
> that the operator specific parts were overlapping the work sessions
> instead of the more big picture sessions.

Great question. The current plan is to maintain the ops summit and mid-cycle 
activities. 

The new format would allow us to reduce overlap between ops summit and cross 
project sessions at the main event, both for the operators and developers who 
want to be involved in either activity.

> 
> On Mon, Feb 22, 2016 at 11:32 AM, Matt Fischer  wrote:
>> Cross-post to openstack-operators...
>> 
>> As an operator, there's value in me attending some of the design summit
>> sessions to provide feedback and guidance. But I don't really need to be in
>> the room for a week discussing minutiae of implementations. So I probably
>> can't justify 2 extra trips just to give a few hours of feedback/discussion.
>> If this is indeed the case for some other folks we'll need to do a good job
>> of collecting operator feedback at the operator sessions (perhaps hopefully
>> with reps from each major project?). We don't want projects operating in a
>> vacuum when it comes to major decisions.
>> 
>> Also where do the current operators design sessions and operators midcycle
>> fit in here?
>> 
>> (apologies for not replying directly to the first message, gmail seems to
>> have lost it).
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Openstack] Rescinding the M name decision

[Lauren Sell]

Good news. After finalizing the trademark checks and giving the community time 
to weigh in, Mitaka will be the name of the M release. 

Thanks again for the great discussion around this topic, and for the 
willingness to be responsive to the concerns of fellow community members.


 On Jul 9, 2015, at 2:18 PM, Tim Bell tim.b...@cern.ch wrote:
 
 Feel free to give input on the Mitaka proposal.
 
 Tim
 
 -Original Message-
 From: Jonathan Bryce [mailto:jbr...@jbryce.com]
 Sent: 09 July 2015 20:52
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Openstack] Rescinding the M name decision
 
 On Jul 9, 2015, at 9:35 AM, Russell Bryant rbry...@redhat.com wrote:
 
 On 07/09/2015 09:19 AM, Neil Jerram wrote:
 In the hope of forestalling an unnecessary sub-thread...
 
 Mita was #1 in the vote, so has presumably already been ruled out by
 OpenStack's legal review.
 
 That is correct.
 
 
 Hi everyone,
 
 I’ve really loved seeing everyone’s understanding and engagement on this
 thread as we worked through the release cycle naming for ‘M’. This was the
 first attempt to follow a new process, so not surprisingly, we found some
 improvements in the algorithm for the future. Still it’s awesome to see how
 constructive and positive the whole conversation has been.
 
 I wanted to provide a quick update on the status of the Foundation’s
 reviews of the names. First, as Russell mentioned above, after the voting
 was completed, we asked our trademark counsel to do checks on the top 3
 names. The first two both had significant trademark issues with existing
 trademark holders in the same space that would have prevented us from
 using the names in most jurisdictions where we have our largest
 communities (US, Europe and Asia). The 3rd choice was relatively low risk
 and so we passed word back to Monty who announced it. Once we realized
 there were other issues with Meiji, we asked for an expedited check of the
 next 3 names: Mitaka, Musashi, and Meguro. The preliminary check shows
 that Mitaka and Meguro both present an acceptable level of risk, while
 Musashi is higher on the risk scale and would probably create problems for
 usage.
 
 At this time, we’re going to do a deeper check on Mitaka, which was the #4
 candidate in voting and would be next in line after Meiji. I know Itoh-san
 mentioned the Mitaka locale has the potential to be associated with certain
 corporations in Japan, but my personal feeling is that may not be significant
 enough to override it’s position in the voting and it’s availability for use.
 
 I’d encourage anyone with other concerns about Mitaka to post those
 within the next 24 hours so we can appropriately consider and discuss
 them. We should have results on the deeper trademark check by next week
 as well and can hopefully settle on a final name.
 
 Thanks again for all the discussion and participation and especially to
 Monty who’s been on the front lines of helping us navigate this. Feel free to
 let me know if you have any other questions,
 
 Jonathan
 210-317-2438
 
 
 __
 
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: OpenStack-dev-
 requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

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

[Lauren Sell]

 On Mar 10, 2015, at 6:00 PM, Devananda van der Veen devananda@gmail.com 
 wrote:
 
 On Tue, Mar 10, 2015 at 12:12 PM Lauren Sell lau...@openstack.org 
 mailto:lau...@openstack.org wrote:
 
 - Operators don’t want the wild west. They are nervous about dissolving the 
 integrated release, because they want a strong filter and rules - dependency 
 mapping, release timing, test coverage - around the most widely adopted 
 projects. I’m not sure we’re giving them a lot of confidence.
 
 We're not lowering the testing standards of existing projects... can you be 
 more clear as to what is creating this concern?

The concern they raised was not necessarily about a testing standard for any 
individual project, but more about the combination of testing across that set 
of the most commonly deployed projects. In other words, if there is no “kernel” 
grouping, it potentially makes it harder to understand the full set of 
dependencies, how well the integration between nova and glance is tested, and 
things along those lines. One item that came up that a lot of them seemed to 
appreciate, for example, was that there was some forcing function for the 
integrated projects that kept their dependencies somewhat aligned and allowed 
them to understand what all they might need to be running to deploy any set of 
those projects. If the projects are all split apart, now they would have to 
deal with understanding that separately for each project they intend to deploy. 
Sean had mentioned in the session that some of this was probably already going 
to be changing, but I do think it was an interesting point that seemed to be 
very widely held among the operators there.

 
 For tags, I think defining a set of projects based on a broad reference 
 architecture / use case like base compute” or “compute kernel” and “object 
 storage” is critical. Those tags will imply the projects share common 
 dependencies and are released together. If we categorize tags that can be 
 applied, compute kernel” could be a higher level category and more 
 prominent. Defining those initial tags should provide enough direction and 
 confidence to start considering new projects.
 
 
 I've started drafting some tags for layers or use cases -- I'm sure 
 they'll get expanded on. I'll post a link once I've uploaded to gerrit.

That’s great news. I think defining those important tags will go a long way in 
giving people confidence in the process and moving forward. 

I believe this is the one you started: https://review.openstack.org/#/c/163236/

Might be worth sharing over to the operators mailing list where Subbu has a 
message about some of the discussions as well: 
http://lists.openstack.org/pipermail/openstack-operators/2015-March/006511.html 
http://lists.openstack.org/pipermail/openstack-operators/2015-March/006511.html

I’m sorry it took me a while to respond to this. Thanks for taking time to 
provide feedback last week.



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

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

[Lauren Sell]

Dissolving the integrated release without having a solid plan and replacement 
is difficult to communicate to people who depend on OpenStack. We’re struggling 
on that front.

That said, I’m still optimistic about project structure reform and think it 
could be beneficial to the development community and users if it’s executed 
well. It gives us the opportunity to focus on a tighter core of services that 
are stable, reliable and scalable, while also recognizing more innovation 
that’s already happening in the community, beyond the existing integrated 
release. Coming out of the ops meetup in Philadelphia yesterday, a few things 
were clear:

- Operators don’t want the wild west. They are nervous about dissolving the 
integrated release, because they want a strong filter and rules - dependency 
mapping, release timing, test coverage - around the most widely adopted 
projects. I’m not sure we’re giving them a lot of confidence.
- They also want some kind of bar or filter for community projects, to provide 
guidance beyond it’s in or out of the community. Tags can help with the nuances 
once they’re in the tent, but I think there’s some support for a bit higher bar 
overall. 
- That said, several people expressed they did not want duplication to prevent 
a project from making it into the tent. They would like to have options beyond 
the core set of projects
- The layers concept came back to play. It was clear there was a distinct 
dropoff in operators running projects other than nova, keystone, glance, 
cinder, horizon and neutron
- The operators community is keen to help define and apply some tags, 
especially those relevant to maturity and stability and general operability

(I know several of you were at the ops meetup, so please jump in if I’ve missed 
or misrepresented some of the feedback. Notes from the session 
https://etherpad.openstack.org/p/PHL-ops-tags.)

Based on feedback and conversations yesterday, I think it’s worth evolving the 
overall project criteria to add 1) a requirement for contributor diversity, 2) 
some criteria for maturity like documentation, test coverage and 
integration/dependency requirements, and 3) make sure there are no trademark 
issues with the project name, since it will be referred to as an OpenStack 
project. I’m also unclear how we’re planning to refer to these projects, as 
“Foo, an OpenStack community project” but not “OpenStack Foo?

For tags, I think defining a set of projects based on a broad reference 
architecture / use case like base compute” or “compute kernel” and “object 
storage” is critical. Those tags will imply the projects share common 
dependencies and are released together. If we categorize tags that can be 
applied, compute kernel” could be a higher level category and more prominent. 
Defining those initial tags should provide enough direction and confidence to 
start considering new projects.

Getting this worked out before the Kilo release would be valuable, because 
having the “last” integrated release without a clear plan forward creates some 
real concerns for those running or productizing the software. Not all tags or 
implementation details need to be defined, of course, but we should be able to 
communicate a solid plan for the layers and categories of tags, as well as the 
different bodies who may be involved in defining tags (ops community, etc) 
before expanding. 


 On Mar 10, 2015, at 2:02 PM, Russell Bryant rbry...@redhat.com wrote:
 
 On 03/10/2015 02:56 PM, Thierry Carrez wrote:
 Russell Bryant wrote:
 One point of clarification:
 
 On 03/10/2015 02:28 PM, Gabriel Hurley wrote:
 Even more concerning is the sentiment of projects we want to
 consciously drop from Russell's original email.
 
 This was in reference to criteria defined in:
 
 http://governance.openstack.org/reference/incubation-integration-requirements.html
 
 For example, we previously had a strict requirement *against*
 duplication of functionality among OpenStack projects unless it was with
 intent and with a clear plan to replace the old thing.  In this new
 model, that would be a requirement we would consciously drop.
 
 It's a requirement we *already* consciously dropped when we approved the
 new projects requirements. Or do you mean you want to come back on that
 decision[1]?
 
 No, I don't want to come back on it.  It was obviously a poorly worded
 comment.  It was an attempt to say that I'd like it if we were closer to
 having tags that covered most of those requirements, except for the
 things we no longer care about, such as the example given.
 
 -- 
 Russell Bryant
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not 

Re: [openstack-dev] [OpenStack Foundation] [tc] Take back the naming process

[Lauren Sell]

Hey Monty,

I’d like to weigh in here, because I think there have been some 
misunderstandings around Lemming-gate. I’m glad you raised your concerns; it’s 
a good test of release naming for us all to discuss and learn from. 

To provide a little context for those new to the discussion, historically, when 
it’s time to name the development cycle, open suggestions are taken on a wiki 
page (https://wiki.openstack.org/wiki/Release_Naming) after which the Technical 
Committee works to create a short list that are then voted on by the entire 
community. Typically, Foundation staff play a role in this process to work with 
our trademark counsel to vet the release names. We register them to ensure our 
rights, and they become significant brands for the OpenStack community, as well 
as all of the companies who are building and marketing their products on 
OpenStack. One of the names that was proposed for the L development cycle was 
Lemming.

So little-known fact, I’m actually a huge fan of rodents (I’ve had several pet 
rats), but I’m afraid the name Lemming conjures up more than a small mammal. 
The dictionary.com definition is a member of any large group following an 
unthinking course towards mass destruction, or if you prefer Urban Dictionary, 
“a member of a crowd with no originality or voice of his own. One who speaks or 
repeats only what he has been told. A tool. A cretin.”

When I heard that Lemming was a consideration, I was a bit concerned. Most of 
all, I care about and am protective of this community, and I think that would 
paint us with a pretty big / easy target. Regardless, I did the due diligence 
with our trademark counsel, and they provided the following feedback: “The 
proposed trademark LEMMING cleared our preliminary search for the usual 
goods/services, subject to the usual limitations.  The majority of 
applications/registrations that others have filed for the term are dead (no pun 
intended).  I take this to mean the brand generally has problems in the 
marketplace due to negative connotation.”

So, I reached out to Thierry and a few of the TC members to share my 
perspective and concern from a marketing standpoint. I have a lot of respect 
for you and this community, and I would hate to jeopardize the perception of 
your work. I am very sensitive to the fact that I do not have a magical 
marketing veto; I was simply providing feedback and trying to bring another 
perspective to the conversation. My sense from talking to them was that Lemming 
was kind of a joke and not a serious option. I also read the notes of the 
following TC meeting, and it didn’t seem like there was much of an issue...so I 
stopped worrying about it.

(TC meeting notes for reference, you can search Lemming in this discussion: 
http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-01-13-20.01.log.txt)

Anyhow, it seems like it’s boiled into a larger issue, and I’m more than happy 
to have the discussion and get more input. I stand by my advice and hope our 
community leaders will make a reasonable decision. I certainly don’t want to 
take the fun out of release naming, but at the end of the day we are all pretty 
fortunate and have quite a bit of fun as part of this community. I was just 
trying to protect it.

Best,
Lauren


 On Jan 27, 2015, at 6:59 PM, Monty Taylor mord...@inaugust.com wrote:
 
 On 01/27/2015 06:05 PM, Jonathan Bryce wrote:
 
 On Jan 27, 2015, at 3:50 PM, Monty Taylor mord...@inaugust.com wrote:
 
 I do not like how we are selecting names for our releases right now.
 The current process is autocratic and opaque and not fun - which is the
 exact opposite of what a community selected name should be.
 
 Autocratic? Could you elaborate?
 
 Right now we're starting from a set list of pre-approved names that
 there was absolutely no participation in the selection of and about
 which discussion is summarily shut down. I know it's with the best of
 intentions, but it's not ok.
 
 I propose:
 
 * As soon as development starts on release X, we open the voting for the
 name of release X+1 (we're working on Kilo now, we should have known the
 name of L at the K summit)
 
 * Anyone can nominate a name - although we do suggest that something at
 least related to the location of the associated summit would be nice
 
 * We condorcet vote on the entire list of nominated names
 
 * After we have the winning list, the foundation trademark checks the name
 
 * If there is a trademark issue (and only a trademark issue - not a
 marketing doesn't like the name issue) we'll move down to the next
 name on the list
 
 If we cannot have this process be completely open and democratic, then
 what the heck is the point of having our massive meritocracy in the
 first place? There's a lot of overhead we deal with by being a
 leaderless collective you know - we should occasionally get to have fun
 with it.
 
 
 If your goal is to actually involve our massive meritocracy, I’d suggest 
 expanding this thread to include at