[Openstack-operators] OpenStack "S" Release Naming Preliminary Results
Hello all! We decided to run a public poll this time around, we'll likely discuss the process during a TC meeting, but we'd love the hear your feedback. The raw results are below - however ... **PLEASE REMEMBER** that these now have to go through legal vetting. So it is too soon to say 'OpenStack Solar' is our next release, given that previous polls have had some issues with the top choice. In any case, the names will been sent off to legal for vetting. As soon as we have a final winner, I'll let you all know. https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_40b95cb2be3fcdf1&rkey=c04ca6bca83a1427 Result 1. Solar (Condorcet winner: wins contests with all other choices) 2. Stein loses to Solar by 159–138 3. Spree loses to Solar by 175–122, loses to Stein by 148–141 4. Sonne loses to Solar by 190–99, loses to Spree by 174–97 5. Springer loses to Solar by 214–60, loses to Sonne by 147–103 6. Spandau loses to Solar by 195–88, loses to Springer by 125–118 7. See loses to Solar by 203–61, loses to Spandau by 121–111 8. Schiller loses to Solar by 207–70, loses to See by 112–106 9. SBahn loses to Solar by 212–74, loses to Schiller by 111–101 10. Staaken loses to Solar by 219–59, loses to SBahn by 115–89 11. Shellhaus loses to Solar by 213–61, loses to Staaken by 94–85 12. Steglitz loses to Solar by 216–50, loses to Shellhaus by 90–83 13. Saatwinkel loses to Solar by 219–55, loses to Steglitz by 96–57 14. Savigny loses to Solar by 219–51, loses to Saatwinkel by 77–76 15. Schoenholz loses to Solar by 221–46, loses to Savigny by 78–70 16. Suedkreuz loses to Solar by 220–50, loses to Schoenholz by 68–67 17. Soorstreet loses to Solar by 226–32, loses to Suedkreuz by 75–58 - Paul ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [forum] We want your session ideas for the Vancouver Forum!
Hey everyone, Please take time to put ideas for sessions at the forum in the TC and/or UC catch-all etherpads or any of the others that are appropriate: https://wiki.openstack.org/wiki/Forum/Vancouver2018 We really want to get as many session ideas as possible so that the committee has too many to choose from :) Here is an idea of the types of sessions to think about proposing: *Project-specific sessions* Where developers can ask users specific questions about their experience, users can provide feedback from the last release and cross-community collaboration on the priorities and 'blue sky' ideas for the next release can occur. *Strategic, whole-of-community discussions* To think about the big picture, including beyond just one release cycle and new technologies *Cross-project sessions* In a similar vein to what has happened at past design summits, but with increased emphasis on issues that are of relevant to all areas of the community If you have organized any events in the past year you probably have heard of or been in some sessions that are perfect for the Forum. -- Kind regards, Melvin Hillsman mrhills...@gmail.com mobile: (832) 264-2646 ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Deprecation Notice: Pika driver for oslo.messaging
Folks, As announced last year the Oslo team has deprecated support for the Pika transport in oslo.messaging with removal planned for Rocky. We're not aware of any deployments using this transport and its removal is not anticipated to affect anyone. More details can be found in the original announcement [0]. This is notice that the removal is currently underway [1]. Thanks, [0] http://lists.openstack.org/pipermail/openstack-operators/2017-May/013579.html [1] https://review.openstack.org/#/c/536960/ -- Ken Giusti (kgiu...@gmail.com) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Poll: S Release Naming
On Tue, Mar 13, 2018 at 07:58:59PM -0400, Paul Belanger wrote:
> Greetings all,
>
> It is time again to cast your vote for the naming of the S Release. This time
> is little different as we've decided to use a public polling option over per
> user private URLs for voting. This means, everybody should proceed to use the
> following URL to cast their vote:
>
>
> https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_40b95cb2be3fcdf1&akey=8cfdc1f5df5fe4d3
>
> Because this is a public poll, results will currently be only viewable by
> myself
> until the poll closes. Once closed, I'll post the URL making the results
> viewable to everybody. This was done to avoid everybody seeing the results
> while
> the public poll is running.
>
> The poll will officially end on 2018-03-21 23:59:59[1], and results will be
> posted shortly after.
>
> [1]
> http://git.openstack.org/cgit/openstack/governance/tree/reference/release-naming.rst
> ---
>
> According to the Release Naming Process, this poll is to determine the
> community preferences for the name of the R release of OpenStack. It is
> possible that the top choice is not viable for legal reasons, so the second or
> later community preference could wind up being the name.
>
> Release Name Criteria
>
> Each release name must start with the letter of the ISO basic Latin alphabet
> following the initial letter of the previous release, starting with the
> initial release of "Austin". After "Z", the next name should start with
> "A" again.
>
> The name must be composed only of the 26 characters of the ISO basic Latin
> alphabet. Names which can be transliterated into this character set are also
> acceptable.
>
> The name must refer to the physical or human geography of the region
> encompassing the location of the OpenStack design summit for the
> corresponding release. The exact boundaries of the geographic region under
> consideration must be declared before the opening of nominations, as part of
> the initiation of the selection process.
>
> The name must be a single word with a maximum of 10 characters. Words that
> describe the feature should not be included, so "Foo City" or "Foo Peak"
> would both be eligible as "Foo".
>
> Names which do not meet these criteria but otherwise sound really cool
> should be added to a separate section of the wiki page and the TC may make
> an exception for one or more of them to be considered in the Condorcet poll.
> The naming official is responsible for presenting the list of exceptional
> names for consideration to the TC before the poll opens.
>
> Exact Geographic Region
>
> The Geographic Region from where names for the S release will come is Berlin
>
> Proposed Names
>
> Spree (a river that flows through the Saxony, Brandenburg and Berlin states of
>Germany)
>
> SBahn (The Berlin S-Bahn is a rapid transit system in and around Berlin)
>
> Spandau (One of the twelve boroughs of Berlin)
>
> Stein (Steinstraße or "Stein Street" in Berlin, can also be conveniently
>abbreviated as 🍺)
>
> Steglitz (a locality in the South Western part of the city)
>
> Springer (Berlin is headquarters of Axel Springer publishing house)
>
> Staaken (a locality within the Spandau borough)
>
> Schoenholz (A zone in the Niederschönhausen district of Berlin)
>
> Shellhaus (A famous office building)
>
> Suedkreuz ("southern cross" - a railway station in Tempelhof-Schöneberg)
>
> Schiller (A park in the Mitte borough)
>
> Saatwinkel (The name of a super tiny beach, and its surrounding neighborhood)
>(The adjective form, Saatwinkler is also a really cool bridge but
>that form is too long)
>
> Sonne (Sonnenallee is the name of a large street in Berlin crossing the former
>wall, also translates as "sun")
>
> Savigny (Common place in City-West)
>
> Soorstreet (Street in Berlin restrict Charlottenburg)
>
> Solar (Skybar in Berlin)
>
> See (Seestraße or "See Street" in Berlin)
>
A friendly reminder, the naming poll will be closing later today (2018-03-21
23:59:59 UTC). If you haven't done so, please take a moment to vote.
Thanks,
Paul
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Ops Meetup, Co-Location options, and User Feedback
Doug Hellmann wrote: > Excerpts from Tim Bell's message of 2018-03-20 19:48:31 +: >> >> Would we still need the same style of summit forum if we have the >> OpenStack Community Working Gathering? One thing I have found with >> the forum running all week throughout the summit is that it tends >> to draw audience away from other talks so maybe we could reduce the >> forum to only a subset of the summit time? > > I support the idea of having all contributors attend the contributor > event (and rebranding it to reflect that change in emphasis), but > it's not quite clear how the result would be different from the > Forum. Is it just the scheduling? (Having input earlier in the cycle > would be convenient, for sure.) > > Thierry's comment about "work sessions" earlier in the thread seems > key. Right, I think the key difference between the PTG and Forum is that one is a work event for engaged contributors that are part of a group spending time on making OpenStack better, while the other is a venue for engaging with everyone in our community. The PTG format is really organized around work groups (whatever their focus is), enabling them to set their short-term goals, assign work items and bootstrap the work. The fact that all those work groups are co-located make it easy to participate in multiple groups, or invite other people to join the discussion where it touches their area of expertise, but it's still mostly a venue for our geographically-distributed workgroups to get together in person and get work done. That's why the agenda is so flexible at the PTG, to maximize the productivity of attendees, even if that can confuse people who can't relate to any specific work group. The Forum format, on the other hand, is organized around specific discussion topics where you want to maximize feedback and input. Forum sessions are not attached to a specific workgroup or team, they are defined by their topic. They are well-advertised on the event schedule, and happen at a precise time. It takes advantage of the thousands of attendees being present to get the most relevant feedback possible. It allows to engage beyond the work groups, to people who can't spend much time getting more engaged and contribute back. The Ops meetup under its current format is mostly work sessions, and those would fit pretty well in the PTG event format. Ideally I would limit the feedback-gathering sessions there and use the Forum (and regional events like OpenStack days) to collect it. That sounds like a better way to reach out to "all users" and take into account their feedback and needs... -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
