there and should kick off
interesting side discussions on infrastructure/QA support.
Regards,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstac
f you need to run one, you can use CIVS
(http://civs.cs.cornell.edu/) since that is what we use for the official
elections: https://wiki.openstack.org/wiki/Election_Officiating_Guidelines
Regards,
--
Thierry Carrez (ttx)
__
traveling to
Austin last week for the OpenStack Summit. I'm sure they will get back
to you as soon as possible.
Regards,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubs
et me say
that those were always the best party in the week. The combination of
quiet setting, smaller attendance, local/cultural content and great food
always made those a treat.
--
Thierry Carrez (ttx)
__
OpenStack Deve
ing
scientists, they ran interesting experiments to see when and where it
made sense.
They will present their findings in the upstream dev track, and I think
it makes a good data point for this discussion:
https://www.openstack.org/summit/austin-2016/summit-schedule/events/734
Thierry Carrez wrote:
[...]
I think it's inappropriate because it gives a wrong incentive to become
a core reviewer. Core reviewing should just be a duty you sign up to,
not necessarily a way to get into a cool party. It was also a bit
exclusive of other types of contributions.
Apparent
I understand the need for calmer parties during the week, I
think the general trends is to have less parties and more small group
dinners. I would be fine with HPE sponsoring more project team dinners
instead :)
--
Thierry Carrez (ttx)
Joshua Harlow wrote:
Thierry Carrez wrote:
Adrian Otto wrote:
This pursuit is a trap. Magnum should focus on making native container
APIs available. We should not wrap APIs with leaky abstractions. The
lowest common denominator of all COEs is an remarkably low value API
that adds considerable
.
Great initiative! I love the bottom-up approach to upstream you follow
on this.
See you in Austin!
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
astructure provider
bit (and not deploy Mesos or Kubernetes themselves).
Let's focus on the infrastructure provider bit -- that is what we do and
what the ecosystem wants us to provide.
--
Thierry Carrez (ttx)
_
update them all, then
refresh all containers that happen to use those packages.
It is totally technically doable, it would be a "sane way to maintain
software" (just a different one), and it would meet the needs of
everyone (the rift between distros and upstream
t was
not raised either when the layout was publicly proposed three weeks ago.
It's a bit late to make changes now, as people built their schedules out
and any change is likely to disrupt someone else.
--
Thie
e body of code we
rely on. If we dump global requirements we would have to replace it with
a lot of manual effort to push convergence overall.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usa
between
"Identity v3 API only devstack" and the "Stable Branch" discussion
(can't remember who/where though).
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
applicable. It doesn't have to be Zing-moderated or
in-training, could be more of a small post-event open brainstorming for
those who would still be around.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing
cool kids to using OpenStack as their
base infrastructure provider. For those we need to make it as
transparent and simple to use their usual tools to deploy on top of
OpenStack clouds. The more they can ignore we are there
f you think your team
would benefit from having them.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
onverge to it. ipaddress seems a lot more used and pulled by a
lot of packages. So long-term solution would be to make docker-py
upstream depend on ipaddress instead...
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing
ackalytics ? At least for a while ?
The only protection against metrics being gamed is to change them often
enough... I'm also a big fan of original retrospective analysis, where
you look at past data and find interesting metrics (rather than
predefine a metric f
that. That is the reason why core reviewers groups rarely grow past
17-18 people, and that is the reason why you need to split larger bodies
of codes into smaller review areas handled by separate groups.
--
Thierry Carrez (ttx)
___
if the turnout still
drops as much.
Long term I'd like to remove the summit pass perk (or no longer link it
to "one commit"). It will likely result in a drop in contributors
numbers (gasp), but a saner electorate.
--
Thierry Carrez (ttx)
__
If done quickly, that should let us keep Monasca deliverables in Mitaka.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
s.
We seem to have a sahara-extra build alright:
http://tarballs.openstack.org/sahara-extra/
Please ignore the noise :)
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questio
(ideally produced by each project team with
tooling and mentoring from the docs team) can pick up from that base
first step, assuming their users have completed that first step
successfully.
--
Thierry Carrez (ttx
k.org/summit/austin-2016/summit-schedule/#day=2016-04-27&summit_types=2&tags=2162
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openst
nstack.org/cgit/openstack/keystone/log/?h=stable/mitaka
If you find an issue that could be considered release-critical, please
file it at:
https://bugs.launchpad.net/keystone/+filebug
and tag it *mitaka-rc-potential* to bring it to the Keystone release
crew's attention.
--
Thie
management,
etc.
Feel free to look at the proposed session and comment:
https://etherpad.openstack.org/p/newton-cross-project-sessions
+1 great idea!
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage
for their sessions.
--
Thierry Carrez (ttx)
DSAustin20160331.pdf
Description: Adobe PDF document
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
/openstack/heat/log/?h=stable/mitaka
If you find an issue that could be considered release-critical, please
file it at:
https://bugs.launchpad.net/heat/+filebug
and tag it *mitaka-rc-potential* to bring it to the Heat release crew's
attention.
--
Thie
k/nova/log/?h=stable/mitaka
If you find an issue that could be considered release-critical, please
file it at:
https://bugs.launchpad.net/nova/+filebug
and tag it *mitaka-rc-potential* to bring it to the Nova release crew's
attention.
--
Thie
lease
file it at:
https://bugs.launchpad.net/sahara/+filebug
and tag it *mitaka-rc-potential* to bring it to the Sahara release
crew's attention.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for
/openstack/trove/log/?h=stable/mitaka
If you find an issue that could be considered release-critical, please
file it at:
https://bugs.launchpad.net/trove/+filebug
and tag it *mitaka-rc-potential* to bring it to the Trove release crew's
attention.
--
Thie
k.org/cgit/openstack/barbican/log/?h=stable/mitaka
If you find an issue that could be considered release-critical, please
file it at:
https://bugs.launchpad.net/barbican/+filebug
and tag it *mitaka-rc-potential* to bring it to the Barbican release
crew's attention.
--
Thie
k.org/cgit/openstack/glance/log/?h=stable/mitaka
If you find an issue that could be considered release-critical, please
file it at:
https://bugs.launchpad.net/glance/+filebug
and tag it *mitaka-rc-potential* to bring it to the Glance release
crew's attention.
--
Thie
October 6, not October 13. Such a date
would also let us more easily accommodate a very likely short Octata
cycle (due to the design summit split).
Let me propose a fix,
--
Thierry Carrez (ttx)
__
OpenStack Development Ma
Matt Riedemann wrote:
1:30pm on Thursday (first slot after lunch is unconference for nova)
would work for me.
OK, I'll make that swap too (unless Josh hits me with a trout over the
night)
--
Thierry Carrez
block that I personally be present in that time
slot.
OK, I'll make the swap happen then.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@list
Would that work ?
--
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
OpenStackClient, Stable and Release to a larger fishbowl room
Cheers,
--
Thierry Carrez (ttx)
DSLayout-20160330.pdf
Description: Adobe PDF document
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
d an issue that could be considered release-critical, please
file it at:
https://bugs.launchpad.net/ceilometer/+filebug
and tag it *mitaka-rc-potential* to bring it to the Ceilometer release
crew's attention.
Thanks!
--
Thie
Matt Riedemann wrote:
On 3/29/2016 2:48 AM, Thierry Carrez wrote:
Matt Riedemann wrote:
I see one problem. The single stable team fishbowl session is scheduled
for the last slot on Thursday (5pm). The conflict I have with that is
the nova team does it's priority/scheduling talk in the
jects.
--
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
onflict for you here ?
--
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-
stack/heat/log/?h=stable/mitaka
If you find an issue that could be considered release-critical, please
file it at:
https://bugs.launchpad.net/heat/+filebug
and tag it *mitaka-rc-potential* to bring it to the Heat release crew's
attention.
--
Thie
k.org/cgit/openstack/cinder/log/?h=stable/mitaka
If you find an issue that could be considered release-critical, please
file it at:
https://bugs.launchpad.net/cinder/+filebug
and tag it *mitaka-rc-potential* to bring it to the Cinder release
crew's attention.
--
at:
http://git.openstack.org/cgit/openstack/ceilometer/log/?h=stable/mitaka
If you find an issue that could be considered release-critical, please
file it at:
https://bugs.launchpad.net/ceilometer/+filebug
and tag it *mitaka-rc-potential* to bring it to the Ceilometer release
crew's attention.
--
Thie
would conflict (a lot of people are involved in both). Maybe we
could swap those two (put stable at 4:10pm and relmgt at 5:00pm). It
looks like that would work ?
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List
hen we add
projects to the Big Tent.
Right. My point was: initially there was a lot of catch-up to do, as a
lot of projects previously in Stackforge qualified under the new
criteria and had to apply and be processed. I think we are done with
that backlog now, and back to normal frequency of project
g you care about is being discussed ! As mentioned in my
candidacy, we need to have that "limits of the tent" discussion soon :)
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questio
(This was also submitted as https://review.openstack.org/#/c/298294)
Hi everyone,
I'd like to submit my candidacy for reelection on the Technical
Committee. For those who don't know me yet, my name is Thierry Carrez, I
use "ttx" as my IRC nickname. I'm currently
we'll gradually push those to the official schedule. The
goal is to have all the content finalized for mid-April.
Thanks all!
--
Thierry Carrez (ttx)
DesignSummitAustin.pdf
Description: Adobe PDF document
__
OpenStack
Foundation does not
special-case core reviewers. Instead, we work hard at limiting the
benefits associated with core reviewing so that people do not pursue
becoming one for the wrong reasons.
--
Thierry Carrez (ttx)
__
reference/projects.yaml in the openstack/governance
repository), since the official project team it's attached to is not
maintaining it.
We should only retire the project if we think nobody will ever again
work on it, which is a slightly different discussion.
--
Thierry Carrez
at:
https://bugs.launchpad.net/neutron/+filebug
and tag it *mitaka-rc-potential* to bring it to the Neutron release
crew's attention.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubsc
tack/zaqar/log/?h=stable/mitaka
If you find an issue that could be considered release-critical, please
file it at:
https://bugs.launchpad.net/zaqar/+filebug
and tag it *mitaka-rc-potential* to bring it to the Zaqar release crew's
attention.
--
Thie
ge to get rid of
it (or approve someone else's change getting rid of it).
Keeping abandoned repositories in your official list does not reflect
well on your project team (or OpenStack in general).
--
Thierry C
ova/log/?h=stable/mitaka
If you find an issue that could be considered release-critical, please
file it at:
https://bugs.launchpad.net/nova/+filebug
and tag it *mitaka-rc-potential* to bring it to the Nova release crew's
attention.
--
Thie
adding the features they want there ?
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack
to tarballs.openstack.org).
Let me know if you have any other question.
Regards,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
y will never fully obtain.
I think it's time to recognize those are different things and separate them.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openst
stall
to produce a deployment -- that thing can then depend on other things
(libraries, packaging/recipes/playbooks), but what we need to
communicate to downstream users is where the entry point is.
I'll follow up on
Barbican is now open for Newton
development, and feature freeze restrictions no longer apply there !
Regards,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
re just about packaging OpenStack things for usage by
outside deployment systems (Ansible, Puppet, Chef, Deb, RPM...). So I'm
not sure your type:deployment tag would apply to OSA.
--
Thierry Carrez (ttx)
__
Open
the last minute. I think this is a case where the TC
looking at the potential names and making their choice will be working
as intended.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage quest
is very active, which is again much appreciated.
Please respond with ack/nack.
He should have been made stable-core years ago ! What was the liberty
stable PTL thinking ? Oh wait
+1
--
Thierry Carrez (ttx)
__
OpenStack Deve
Emilien Macchi wrote:
On Thu, Mar 17, 2016 at 1:29 PM, Thierry Carrez wrote:
Emilien Macchi wrote:
On Thu, Mar 17, 2016 at 11:43 AM, Kirill Zaitsev
wrote:
Is it too late to ask for a half-day Contributors Meetup for murano?
We had an extremely successful contributors meetup in Tokyo and
guarantee *all*
your sessions will overlap with Nova sessions. We'll do what we can to
reduce overlap with Ironic/QA/Infra.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubs
is now open for Newton
development, and feature freeze restrictions no longer apply there !
Regards,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
open for Newton
development, and feature freeze restrictions no longer apply there !
Regards,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@list
hes of Heat and Neutron are now open for
Newton development, and feature freeze restrictions no longer apply there !
Regards,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
to find someone caring enough about it to persist in pushing those
changes, otherwise it just doesn't happen.
We could have a squad of "convergers" that would define a very small
list of targets every cycle an
with another
team, or just gather in one corner of the large room full of roundtables
we'll have for lunch...
At this stage given available room sizes I'd recommend the latter.
--
Thierry Carrez (ttx)
__
OpenSt
://bugs.launchpad.net/sahara/+filebug
and tag it *mitaka-rc-potential* to bring it to the Sahara release
crew's attention.
Note that the "master" branches of Sahara are now open for Newton
development, and feature freeze restrictions no longer apply there !
Regards,
--
Thie
nce is now open for Newton
development, and feature freeze restrictions no longer apply there !
Regards,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
nt, and feature freeze restrictions no longer apply there !
Regards,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:u
esource-constrained situation (and I
think it is), it's better to clearly set expectations and close the
wishlist bugs feedback mechanism, rather than keeping it open and
completely ignore it.
--
Thierry Carrez (ttx)
__
Open
p those newton etherpads :)
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/
Tony Breeds wrote:
On Tue, Mar 15, 2016 at 06:28:14PM +0100, Thierry Carrez wrote:
The second issue is that we don't have any way to run an election on the
project, since we don't have a way to determine "contributors" (or rather,
the only voter and potential candidate und
tan's answer correctly, it will
naturally end up in the process where the TC ends up picking the PTL. It
feels natural if you're the only candidate that we would pick you, but
that will likely have to wait until the end of the election period.
--
Thierry Carrez (ttx)
___
efore that requirement. It was approved 7 months
ago and still no sign of activity, so it's not completely crazy to kick
it back to non-official status (especially now that it doesn't trigger
any repository rename).
I'll ask Monty the new PTL about his plans there :)
--
ss the training), and unnecessarily fuels the us vs. them attitude.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:uns
Andreas Jaeger wrote:
On 03/09/2016 09:47 AM, Thierry Carrez wrote:
Jeremy Stanley wrote:
On 2016-03-08 15:13:40 -0500 (-0500), Corey Bryant wrote:
[...]
I'm only seeing neutron-vpnaas-8.0.0.0b3.dev1.tar.gz on
https://tarballs.openstack.org/neutron-vpnaas. Do we need an
update there?
uce a normal tarball again, but I
don't know if that's sane with respect to the current release
schedule.
Could we retrigger a neutron-vpnaas-tarball job pointing to the
8.0.0.0b3 tag so that the tarball is properly generated and uploaded ?
--
Thie
://tarballs.openstack.org/neutron-vpnaas/neutron-vpnaas-8.0.0.0b3.tar.gz
Hi Thierry,
I'm only seeing neutron-vpnaas-8.0.0.0b3.dev1.tar.gz on
https://tarballs.openstack.org/neutron-vpnaas. Do we need an update there?
Something weird happened there... Let us investigate and get back to you.
--
Thierry C
leads that Fuel seems to want).
I'd recommend that you run that part yourselves once the PTL is elected.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstac
task to FixReleased.
However, since unfortunately in Launchpad only "drivers" can fully
create series bugtasks, it is quite common that we have a change closing
the bug, but no corresponding bugtask to FixRelease. For those bugs
For more information on the release schedule and the freezes, please
see: http://releases.openstack.org/mitaka/schedule.html
And yes, there are only 5 weeks before the end of the Mitaka cycle !
Cheers!
--
Thierry C
/cgit/openstack/election/tree/events.yaml
Regards,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Tim Bell wrote:
On 26/02/16 18:08, "Thierry Carrez" wrote:
2. Community split
There is fear that the contributor-specific event will separate the
community into two groups, with developers skipping the main event and
non-developers not providing any feedback to the contributo
Thierry Carrez wrote:
1. "Two trips instead of one"
There is a section of attendees which benefited from a single event:
in-between people who do not generally go to any midcycle events and
successfully split their attention between the design summit and the
main conference when
e "only us around" aspect.
I'll answer those concerns in a reply email.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.opens
up and not around to review patches.
This patch is now merged, things should be good to go again.
Thanks Sean for unbreaking the world once again!
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage
nding both events, you indeed save on
pure flight costs. But since you have to cover for conference hotel
rooms and food over the weekend and otherwise compensate employees for
being stuck there over the weekend, the gain is not that significant...
--
Thierry C
We can't really prevent people from organizing those anyway :) I just
hope social in-person team gatherings will not be needed as much with
this split. What may still be needed are mid-cycle "sprints" to achieve
specific objectives: those could happen in hackathon space at the main
Henry Nash wrote:
On 22 Feb 2016, at 17:45, Thierry Carrez wrote:
Amrith Kumar wrote:
[...]
As a result of this proposal, there will still be four events each year, two "OpenStack
Summit" events and two "MidCycle" events.
Actually, the OpenStack summit becomes the mid
thinking would be to give preferential rates to access the main
summit to people who are present to other events (like this new
separated contributors-oriented event, or Ops midcycle(s)). That would
allow for a wider definition of "active community member" and redu
/. I just don't
think every contributor needs to be present at every OpenStack Summit,
while I'd like to see most of them present at every separated
contributors-oriented event[tm].
--
Thierry Carrez (ttx)
__
ore easily
justify going to the main OpenStack Summit user conference event, and to
regional Ops gatherings.
But things are still pretty open on that front, so let's see what the
feedback is.
--
Thierry Carrez (ttx)
__
are or hardware. So I'm not sure
we want either of them.
Any other suggestion ?
Or maybe we should not try to clarify what "no open core" means in 2016,
and rely on TC members common sense to judge that ?
--
Thierry Carrez (ttx)
___
Daniel P. Berrange wrote:
On Mon, Feb 22, 2016 at 04:14:06PM +0100, Thierry Carrez wrote:
Hi everyone,
TL;DR: Let's split the events, starting after Barcelona.
Yes, please. Your proposal addresses the big issue I have with current
summits which is the really poor timing wrt start of eac
701 - 800 of 2055 matches
Mail list logo
