ommon-openstack-ml-topics
--
Thierry Carrez (ttx)
__
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
+ free as in beer solution based on WebRTC:
https://meet.jit.si/
No account needed, no participant limit.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
some extra communication to work seamlessly.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
team using the openstack/release repository.
This change applies the key to already-known exceptions: please review
those and suggest any other exception that I missed!
Cheers,
--
Thierry Carrez (ttx)
__
OpenStack Development Ma
? If from Pypi
maybe their clocks are off or they do some kind of processing that
affects the timestamp...
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
from it?
My assumption is that it's "something we plan to minimally maintain
because we depend on it". in which case all options would work: the
exact choice depends on whether there is anybody interested in helping
maintaining it, and where those contributors prefer to do the work.
frequency, I agree with mnaser that once per month might be
too rare. That means only 5-ish meetings for a given a 6-month
membership. But that can work if we use the meeting as a formal progress
status checkpoint, rather than a way to dis
Hi everyone,
In OpenStack, libraries have to be released with a
cycle-with-intermediary model, so that (1) they can be released early
and often, (2) services consuming those libraries can take advantage of
their new features, and (3) we detect integration bugs early rather than
late. This
services, it's probably time to address that.
To that end, I'm sending this to see if anyone is aware of any
reasons
we shouldn't go ahead and tag a 1.0 of Castellan.
+ 1
+1
Propose it and we can continue the discussion on the review :)
--
Thierry Carrez (ttx
l discuss such areas
that are a particularly good match for users to get involved.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subj
Ben Nemec wrote:
On 9/25/18 3:29 AM, Thierry Carrez wrote:
Absence of priorities was an initial design choice[1] based on the
fact that in an open collaboration every group, team, organization has
their own views on what the priority of a story is, so worklist and
tags are better ways
/StoryBoard/Priority
--
Thierry Carrez (ttx)
__
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
-- the separate list has outlived its usefulness.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
lip of pen? Should it be
"2020-02-23" ?
Can someone tell some reason about this? Thanks a lot.
It probably is a slip of pen. Thanks for noticing !
I proposed the fix: https://review.openstack.org/604309
--
a long way to solve the "default
experience" as it provides a nice UI by default with "always connected"
behavior that most people expect from such communication media those days.
The main blocker AIUI is to integrate it with some authentication
mechanism(s)...
--
unity members to reach out on local social networks... But
I'm reluctant to pass an official resolution to recommend that TC
members engage on specific platforms because "everyone is there".
--
Thierry Carrez (ttx)
erability, and
therefore be detrimental to the OpenStack mission rather than helping it.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@list
ving the request.
Let us know if you have other questions !
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
You mention Ildiko and Lance: they did that line of
work without being elected.
So I would definitely support having champions to drive SIG
cross-project priorities, and use the TC both to support them and as a
natural pool of champion candidate
ur service, Emilien! Your quality input on both technical
and social aspects of the TC activity helped us move forward over those
past 2 years. Please consider serving again in the future!
--
Thierry Carrez (ttx)
__
OpenStack D
g/software/project-navigator/openstack-components#openstack-services
Regards,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:u
100% sure we won't need it anymore, but
that sounds a bit silly.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
d command).
For more information on the bot commands, please see:
https://git.openstack.org/cgit/openstack/ptgbot/tree/README.rst
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
. ;)
As someone who just had to process a dozen of ML moderation requests
about non-member posting to lists due to replies to a cross-posted
topic, I wholeheartedly support the list merging :)
--
Thierry Carrez (ttx
Matt Riedemann wrote:
On 8/23/2018 4:00 AM, Thierry Carrez wrote:
In the OpenStack governance model, contributors to a given piece of
code control its destiny.
This is pretty damn fuzzy.
Yes, it's definitely not binary.
So if someone wants to split out nova-compute
into a new repo/project
of team
plans for Stein encouraged. A presentation of Sphinx in OpenStack by
stephenfin will open the show.
Hopefully this time we won't have snow disrupting that schedule.
Cheers,
--
Thierry Carrez (ttx)
__
OpenStack
t features that operators and users need get
delivered to them ? That keeping placement inside Nova governance will
yield better results ?
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage
n core nor proprietary)
2/ I have no idea how usable Redis core is in our use case without the
now-proprietary modules (or how usable Redis core will stay in the
future now that Redis labs has an incentive to land any "serious"
features in the proprietary modules rather than in core).
--
Trinh Nguyen wrote:
Here is my proposed action plan for Searchlight in Stein. The ultimate
goal is to revive Searchlight with a sustainable number of contributors
and can release as expected.
[...]
Thanks again for stepping up, and communicating so clearly.
--
Thierry Carrez (ttx
stated in the past that default drivers had to be open source, so
if anything depends on commons-claused Redis modules, they would
probably have to find an alternative...
Which OpenStack components are affected ?
--
Thierry Carrez (ttx
cumenting general expectations and shared understandings, so
that you create a common culture and trust by default people to apply it.
What would you suggest we do to improve that in this specific case?
--
Thierry Carrez (ttx)
__
sting members in that group to
directly add you:
https://review.openstack.org/#/admin/groups/964,members
(NB: this group looks like it should be updated :) )
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing Li
as deployment deliverable.
OK, so how about we make sure *Kolla-Ansible* is present both in the map
and the components list ?
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
maintained that their tooling is more than just a pile of recipes.
Once we have all that display driven through YAML files stored in a Git
repo under Gerrit, we'll be able to fine tune that content, create more
subcategories etc.
A bit of patience :)
--
Thierry C
case that Kolla should be used directly by deployers
(rather than run it though Ansible with Kolla-Ansible), and therefore
should appear as a deployment option on the map as well ?
--
Thierry Carrez (ttx)
__
Open
hotel, but our hotel block closes TODAY. So book now if you want to be
at the center of the activity !
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
s... The Board and the TC co-own the mission and
the scope of OpenStack. The TC is in charge of the technical side,
especially when it comes to implementation. The Board is in charge of
the trademark side (it ultimately owns what can be called "OpenStack").
--
Thierry Carrez (ttx)
__
to the mentioned contact points.
For more general information on how to contribute, you can check out our
contribution portal:
https://www.openstack.org/community/
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List
tion or coordination
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailma
, it looks healthy (specs getting completed
along the way, not approving a lot more than you can actually take).
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack
y to apply the Brian Waldon exception.
I'm not even sure we need to apply the Brian Waldon exception, as noisy
trains seem to be a permanent geographic feature of Denver.
--
Thierry Carrez (ttx)
__
OpenStack Development Ma
this time !
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman
for the results of the PTL election process, please join me in
extending congratulations to the following PTLs:
[...]
Congrats to all, and thank you for stepping up and helping stewarding
our various project teams !
--
Thierry Carrez (ttx
SIGs we have been recentering project teams on
upstream code production.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstac
into alternatives, we should evaluate their
spam-filtering abilities...
[1]
https://www.reddit.com/r/Slack/comments/71bd1h/need_help_preventing_pm_spam/
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage
inconvenience this may cause.
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132392.html
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
ade horror stories... The
content should generally fit within 20 min to leave room for Q
If you have ideas, please fill:
https://etherpad.openstack.org/p/PTG4-postlunch
In a few weeks the TC will review suggestions there and pick things that
fit the bill.
Cheers,
--
Thierry C
really expect Stein to feel that much longer, or work planning
to be significantly impacted.
Cheers,
[1] http://lists.openstack.org/pipermail/foundation/2018-June/002598.html
--
Thierry Carrez (ttx)
__
OpenStack
n't
have my launchpad credentials with me to SSO login to Gerrit.
Sure, I'll reference this email there. Thanks Luke, have a great PTO!
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
liaison,
meeting chair...) then it should not be too much extra work.
PTLs are responsible by default for a lot of things in their projects,
but all of those things can be delegated to others.
--
Thierry Carrez (ttx
,
Monasca, Masakari, and Mistral... Which day would be best for you given
the current schedule (assuming we don't move anything else as it's too
late for that).
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List
Thierry Carrez wrote:
Hi everyone,
Last month we published the tentative schedule layout for the 5 days of
PTG. There was no major complaint, so that was confirmed as the PTG
event schedule and published on the PTG website:
https://www.openstack.org/ptg#tab_schedule
The tab temporarily
enver_2018
See you there !
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-b
To make this transition.
I think it makes a lot of sense. Stable branch maintenance was always a
bit of an odd duck in the project teams (owning no repository), and is
technically a downstream activity (post-release) with lots of potential
to get users involved.
--
Thierry Carrez (ttx
r vCenter users) get us the alignment
you seek ?
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lis
much more interested in
discussing what to add or change in order to make it usable for more use
cases while continuing to serve the needs of our existing users. And I'm
not convinced that's an either/or choice...
--
Thierry C
mentions and follow
links if interested. The bot could even serve yesterday's report to you
in privmsg if you asked for it. That feature would, I believe, be reused
in other channels.
--
Thierry Carrez (ttx)
__
OpenStack
nStack has a lot of
successful users, and IMHO we can't afford to break them. Proposing
incremental, backward-compatible change is therefore more productive
than talking about how you would design OpenStack if you started today.
--
Thierry C
t:
https://openstackfoundation.formstack.com/forms/travelsupportptg_denver_2018
See you there !
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
couver-2018/summit-schedule/events/20968/beyond-datacenter-cloud-the-future-of-the-openstack-foundation
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...
-independent...
I seem to remember there were drawbacks in branching tempest, though...
Can someone with functioning memory brain cells summarize them again ?
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List
in joining that, I'm happy allocating space on Monday
or Tuesday for that...
Otherwise there is always the option to schedule in reservable space
using ptgbot on the fly :)
--
Thierry Carrez (ttx)
__
OpenStack Deve
onale" section that is meant to justify how the
ecosystem benefits from having this tag defined.
[1]
https://governance.openstack.org/tc/resolutions/20141202-project-structure-reform-spec.html#provide-a-precise-taxonomy-to-help-navigating-the-ecosystem
--
Thierry C
Thoughts on those suggestions? Other suggestions?
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
" across all of OpenStack. But as Jeremy and Doug
mentioned, the reality is that we bailed on providing that view through
Launchpad a long time ago.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not fo
r to leave room
for rocky and stein point releases, we need to skip 1.18.1 and 1.19.0,
and go directly to 1.20.0. I think we can build release checks to ensure
that, but that's something to keep in mind.
Thoughts ?
[1] It's never too early
e team.
>
> Please let me know what you think,
+1
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
ery year. The second PTG
of the year could then be kept as a separate event, or put next to that
"upgraded" OpenStack Day.
Thinking on this is still very much work in progress.
--
Thierry Carrez (ttx)
_
ction data (what turbo-hipster did) and the challenges to
share deidentified data to that purpose.
Cheers,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstac
report instead
of quantitative/tags.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
you use a change proposed to the
openstack/releases repository, so that we can test that the release will
work. Don't hesitate to ping us on #openstack-releases or read the doc at:
http://git.openstack.org/cgit/openstack/releases/tree/README.rst
--
Thierry Carrez (ttx
erprets them the way they
want... So I think that could use some explicit clarification.
[ This tangent should probably gets its own thread to not disrupt the
no-nitpicking discussion ]
--
Thierry Carrez (ttx)
__
it ? If not,
that's probably something I can do :)
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
quot; list items, so that they contain more business-value explanation
and get more regular status updates at the Board...
If I remember correctly, Chris Price, dims and you volunteered :) I'm
happy to help too.
Is that something you would like to track on this document as well ?
--
Thierry C
likely to be changed in the near
future to a more neutral name, but I would keep the "hosted on" language
to describe the relationship.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not fo
the
subproject, let alone develop on or against it, for fear that it wind up
some poor end-user's support nightmare. [...]
Yes, that's fair... and why my original suggestion was to do a (regular)
qualitative report that would use words rather than binary tags.
--
Thierry Carrez (ttx
ing change" and "follow-up separate change" as to what is the
recommended way to fix nits.
To clarify, the proposal here is to encourage the posting of a follow-up
change.
--
Thierry Carrez (ttx)
__
OpenStack Development M
could add a new team tag
(low-activity ?) that would appear for all projects where the activity
is so low that the team diversity tags no longer really apply.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List
both sessions can be found at:
> https://etherpad.openstack.org/p/YVR-forum-fast-forward-upgrades
You should add it to the list of all etherpads at:
https://wiki.openstack.org/wiki/Forum/Vancouver2018
--
Thierry Carrez (ttx)
___
an
itself, which confuses the messaging around the base service addition a
bit ("any Castellan-supported secret store as long as it's Barbican")
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not
9, act now !
More details:
https://www.eventbrite.com/e/project-teams-gathering-denver-2018-tickets-45296703660
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstac
collaborating. We can raise the topic,
but in the end it is a User Committee decision though, since the LCOO is
a User Committee-blessed working group.
Source: https://governance.openstack.org/uc/
--
Thierry Carrez (ttx
://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21740/tc-retrospective
You mean Thursday, right ?
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
in the governance repo
(which was the reason for moving to storyboard in the first place).
What do others think?
I don't have a strong opinion, small preference for (2). At the end of
the cycle, the goal becomes just another story with leftover tasks.
--
Thierry Carrez (ttx
tracked at SIG level, beyond code ownership. It's not an easy change,
with project teams being so integral to our culture, but it is something
we should start looking into.
--
Thierry Carrez (ttx)
__
OpenStack Deve
e "massive public
cloud" to suddenly invest hundreds of FTEs to cover their use case. Or
we can be aware of the local maximum trap, go a bit out of our ways to
serve both ends of the spectrum, and realize that it puts us in a lot
better place.
--
Thierry Carrez (ttx)
__
ot;contributors" with various backgrounds but a single
objective, please add to it and join the session !
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
-hour-conversation-starters
Cheers,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org
s, with only one day
of keynotes), more than we used to have. We decided to use the 3rd room
as a room available to schedule follow-up sessions, in case 40 min does
not cut it. More details on that later once the schedule is approved.
--
Thierry Carrez (ttx)
_
ts, you can
read the Infra manual at:
https://docs.openstack.org/infra/manual/creators.html
While it's geared towards creating NEW projects, the guide can be
helpful at pointing to the right files and processes.
--
Thierry Carrez (ttx)
__
help us tackle
this "unified experience" problem you raised. The formation of the
upgrades SIG, or the self-healing SIG is a sign that times change. Maybe
we need to push in that direction even more aggressively and start
thinking about de-emphasizing project team
ut it's pretty recent :)
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailm
t of exercise more often.
What do you think should be the right forum for continuing that
discussion? Is that something you think we should discuss at the
Forum[tm] ? Or more as an asynchronous discussion at the TC level ?
--
T
have trouble placing a new project
on the map, it's symptomatic of a deeper issue (like unclear scope /
usage definition) that needs to be discussed early rather than late.
[1] https://www.openstack.org/openstack-map
--
Thierry Carrez (ttx)
__
ts/reports/OpenStack-AnnualReport2017.pdf
See pages 7-9. Obviously not optimal (not everybody answered, and some
of the responses are a bit off-topic), but we had limited time to pull
it off and I think it's a good first step. We can
the scenes. A Zun deployer absolutely needs
to know that.
I hope that the Constellation concept will help the latter traverse our
product map more efficiently.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List
there, and we could do a lot better by
engaging with them more directly.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:u
t; How would our community be different, in positive and negative ways,
> if we were more strict about avoiding such overlap?
I feel like we have been pretty strict with competitive projects. I fear
that being stricter would completely close th
So I'd like to see the TC members (and more generally the
people interested in governance problems) more active in discovering
issues, proactively addressing them and owning the changes.
--
Thierry Carrez (ttx)
__
OpenStack Develo
ried. That is why this discussion is useful: comparing notes
on how we answer that difficult question, understanding where everyone
stands, helps us converge to a general consensus of the goals we are
trying to achieve when defining "OpenStack" scope, even if we disagree
on the particu
1 - 100 of 1930 matches
Mail list logo
