therpad.openstack.org/p/common-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
pen source + 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: ope
ight
need 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:unsubs
ement 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 Deve
from ? 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: openstac
move away 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
rding 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 t
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 wor
base 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 :)
--
oject" -- and we'll 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: openst
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 to
i.openstack.org/wiki/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
+1 -- 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
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
--
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)...
--
and discussed in a single language). We can even
encourage community 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)
would significantly hurt interoperability, and
therefore be detrimental to the OpenStack mission rather than helping it.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
fore approving 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:un
to do
that kind of work. 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 p
eam.
Thanks for your 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)
__
ck.org/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?subj
t there until we are 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.ope
bot
admins (ttx, diablo_rojo, infra...) to create a track for you (which
they can do by getting op rights and issuing a ~add command).
For more information on the bot commands, please see:
https://git.openstack.org/cgit/openstack/ptgbot/tree/README.rst
--
Thierry Carrez (ttx)
___
. ;)
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/pr
aries 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)
__
tely ensure that 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
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
p to them).
The TC 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 ?
--
it's generally
done by documenting 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)
___
e existing 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 Maili
le 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)
Unsubs
aintained 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 :
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)
__
OpenStack Dev
in the PTG
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: openstac
er is... 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 (tt
o 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
not prevent cooperation or coordination
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstac
, 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
tunity 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 Deve
with this effort for all this time !
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.open
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
and with
the introduction of SIGs we have been recentering project teams on
upstream code production.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openst
As we look 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
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
upgrade horror stories... The
content should generally fit within 20 min to leave room for Q&A.
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,
--
T
esn't 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)
__
I don'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 u
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
tcher,
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 Developme
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
ptg_denver_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/
https://review.openstack.org/584206
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
l want to do an
AWS, but we need to care about our vCenter users) get us the alignment
you seek ?
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@
ilding it today. I'm 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
ting 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)
_
ng it.
Another thing we need to keep in mind is that OpenStack 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 ho
g the event:
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?subj
ttps://www.openstack.org/summit/vancouver-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)
lease-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 (no
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
es a "rationale" 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
.
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:u
and
"what's landed" 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)
__
OpenSta
ase that. In order 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 ?
t; the 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:unsubsc
summit every 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
switch to a more qualitative/prose report instead
of quantitative/tags.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.ope
ggest 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 C
atibility if someone started to use that feature right away. It's
the issue with implicit rules: everyone interprets 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
f 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:unsubs
eded" 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 ?
--
" is 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 Li
using 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.
--
There still seems to be some confusion between "new patchset over
existing 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)
_
work), we 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
th 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)
___
epend on Barbican
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 Developme
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
penly 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
://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
es 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 C
t like work in Kubernetes is
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)
___
yment" or the "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
/tc-office-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.ope
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)
_
ic topics, can 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-emphasizi
ect/923
But 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.or
uld do that sort 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
t every time I 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 ste
o
actually do its magic behind 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)
__
OpenS
ributions from 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.openstac
s all shades of grey.
> 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
ong. 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)
__
OpenSt
way we interpret them can
still be varied. 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" s
1 - 100 of 2055 matches
Mail list logo
