is one
such tool, simple enough to understand.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
tarball ASAP. I took down the wrong one. Sorry for the
inconvenience... the issues here are not a policy problem, they are just
human error in the original tag, complicated by CI staleness that made
us think we fixed it while we didn't.
--
Thierry Carrez (ttx
,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
patchsets, but which
can be set or unset by any core/driver/ptl (to be determined). So if the
PTL sets the procedural Workflow-2 at feature freeze, I can clear it
when RC1 is published.
Not sure that's supported in Gerrit though :)
--
Thierry Carrez (ttx
this world.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Dan Smith wrote:
Looks reasonable to me.
+1
+1
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
://wiki.openstack.org/wiki/StoryBoard/Task_Lists
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
single OpenStack release so
far), we have struggled to have the visibility, long-term thinking and
discipline to stick to it in the past. If you look at the post-summit
plans and compare to what we end up in a release, you'll see quite a lot
of differences :)
--
Thierry Carrez (ttx
and will follow them. He also signs up to do enough of them to
limit the opportunistic and accidental issues.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
private gathering. The goal of the workshop would be published in
advance, and people could opt to join that. It would be totally optional.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
convergence we struggle in adoption. We need to understand why, and if
this is fixable.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
bugs and security issues.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
now, and the very few resources that have the unique
combination of knowledge and will/time to spend on those is quickly
dying of burnout.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org
with an existing openstack project sounds like a recipe for
making sure openstack doesn't mean anything upstream anymore.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
. Let's wait for the
feedback of the affected programs to see if it's compatible with their
own plans.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Zane Bitter wrote:
On 11/08/14 05:24, Thierry Carrez wrote:
This all has created a world where you need to be*in* OpenStack to
matter, or to justify the investment. This has created a world where
everything and everyone wants to be in the OpenStack integrated
release. This has created more
to be staggered to keep availability levels
What minimal level of hot would be acceptable to you ?
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
would still have programs (teams) and projects (the
code repos that team is working on).
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
. That
encourages everyone to find a lazy consensus. That part of the PTL job
works. Let's fix the part that doesn't work (scaling/burnout).
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org
clear and public that
there is a gap. Today the gap just ends up on the PTL's list of other
things to also do.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
Daniel P. Berrange wrote:
On Fri, Aug 22, 2014 at 02:33:27PM +0200, Thierry Carrez wrote:
Hi everyone,
We all know being a project PTL is an extremely busy job. That's because
in our structure the PTL is responsible for almost everything in a project:
- Release management contact
- Work
Zane Bitter wrote:
On 22/08/14 08:33, Thierry Carrez wrote:
We also
still need someone to have the final say in case of deadlocked issues.
-1 we really don't.
I know we disagree on that :)
People say we don't have that many deadlocks in OpenStack for which the
PTL ultimate power
by polling.
Could you expand on that ? Do you need some kind of user-facing queue
service, or is there something in the marc^WZaqar approach that makes it
especially appealing ?
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev
practices.
In smaller programs, I would expect the PTL to keep filling most, if not
all, of those roles. As long as the PTL is not overworked, the roles are
well-known and everyone knows who to contact, it works.
--
Thierry Carrez (ttx)
___
OpenStack-dev
). But then if
things go badly wrong, you require the TC to step in with threats of
removal of OpenStack and/or to force an election/vote in the middle of
the crisis. I'm really failing to see how that would result, in those
hypothetical crisis scenarios, in a better outcome.
--
Thierry Carrez (ttx
it the way it is (with the PTL being responsible for all those
duties), it's totally fine.
It's a framework for clear delegation within the current system, not a
whole new system :)
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev
a basic new projects in existing
program requirements list as a governance repo change ? Then we could
iterate on it.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
Doug Hellmann wrote:
On Aug 22, 2014, at 5:59 AM, Thierry Carrez thie...@openstack.org wrote:
TL;DR:
Let's create an Oslo projectgroup in Launchpad to track work across all
Oslo libraries. In library projects, let's use milestones connected to
published versions rather than the common
don't think we need a role for logistics (chairing
meetings and organizing meetups), design summit planning, roadmapping,
user point of contact, or spokesperson -- as I expect the PTL to retain
those roles anyway...
--
Thierry Carrez (ttx)
___
OpenStack
doable would a migration to saml at this point be ? I'm trying to find a
solution so that we can ship this feature :)
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
me know.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Thierry Carrez wrote:
Doug Hellmann wrote:
This makes sense to me, so let’s move ahead with your plan.
OK, this is now done:
Project group @ https://launchpad.net/oslo
Oslo incubator: https://launchpad.net/oslo-incubator
oslo.messaging: https://launchpad.net/oslo.messaging
General blueprint
, or
documenting/mentoring other people so that they can do it in your place.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
.
[1] https://wiki.openstack.org/wiki/ProjectTypes
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
that discussion before, and I know there is a dangerous potential
quality slope there -- I just fail to see any other solution to bring
that 750/21=36 figure down to a bearable level, before we burn out all
of the Nova core team.
--
Thierry Carrez (ttx
Sean Dague wrote:
On 08/28/2014 03:06 PM, Jay Pipes wrote:
On 08/28/2014 02:21 PM, Sean Dague wrote:
On 08/28/2014 01:58 PM, Jay Pipes wrote:
On 08/27/2014 11:34 AM, Doug Hellmann wrote:
On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org
wrote:
Day 1. Cross-project sessions
Anne Gentle wrote:
On Wed, Aug 27, 2014 at 7:51 AM, Thierry Carrez thie...@openstack.org
mailto:thie...@openstack.org wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from
about is not really about Project Types anyway.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
design summit time?
Sure, that's what Anne probably meant. Time for the program behind every
incubated project.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
.
That really means *today is the last day for feature reviews*.
So please plan that extra review effort today, rather than tomorrow !
Thanks everyone for helping us do a successful Juno release.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack
Hayes, Graham wrote:
On Fri, 2014-08-29 at 17:56 +0200, Thierry Carrez wrote:
Hayes, Graham wrote:
Would the programs for those projects not get design summit time? I
thought the Programs got Design summit time, not projects... If not, can
the Programs get design summit time?
Sure, that's
commits).
Let me know what you think,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
monkey) to
untarget all features that are not already gating: only features with
approved patches stuck in the gate will be kept on the list.
Thanks for helping us do a successful Juno release!
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
on that? Should we reboot the project?
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
want to say that in OpenStack, organizational structure reflects
how we work, not the other way around. If we need to reorganize
official project structure to work in smarter and long-term healthy
ways, that's a really small price to pay.
--
Thierry Carrez (ttx
(yet) apply to currently-integrated
projects...
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
and where we use
all the summit space available for pods :)
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
on to another project)
We'll have to design some novel pod-switching algorithm, but I kinda
want to know how many pods we can have before we start designing. I'm
visiting the space again on Monday.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev
release to finalize the summit schedule, so
plenty of time. Also there will be Kilo PTLs elections in the middle of
this (end of September), and the Kilo themes are actually a Kilo PTL thing.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack
Tim Bell wrote:
-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org]
Sent: 04 September 2014 16:59
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Zaqar] Comments on the concerns arose during
the TC meeting
Sean Dague wrote:
[...]
So
at the
impossible task of keeping the Nova ship straight in troubled waters
while we head toward the Juno release port.
Regards,
[1] https://wiki.openstack.org/wiki/FeatureFreeze
[2] https://wiki.openstack.org/wiki/StringFreeze
[3] https://wiki.openstack.org/wiki/DepFreeze
--
Thierry Carrez (ttx
.
Please note that the Kernel subsystem model is actually a trust tree
based on 20 years of trust building. OpenStack is only 4 years old, so
it's difficult to apply the same model as-is.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev
every time you go to support a FFE.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
of sense but it also has a lot of documentation
consequences. If it was ready to merge and had the necessary reviews
piled up I would +1 this but the way it stands now (and given Glance's
current review velocity) I'm more leaning towards -1.
Cheers,
--
Thierry Carrez (ttx
, and the current Glance review velocity is not exactly feeding
my hopes. +0 as far as I'm concerned, and definitely -1 if it takes more
than one week.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org
@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
It would also be great if the contents of that list matched the
Launchpad milestone page we use to track progress on them:
https://launchpad.net/nova/+milestone/juno-rc1
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev
On Sep 5, 2014 3:30 PM, Matt Riedemann mrie...@linux.vnet.ibm.com
mailto:mrie...@linux.vnet.ibm.com wrote:
On 9/5/2014 5:10 AM, Thierry Carrez wrote:
Hi everyone,
We just hit feature freeze[1], so please do not approve
changes that add
features or new
and
will cause unexpected behaviours (see [1]) like gate failures. In our
case this caused non-deterministic failures on the dsvm-functional test
suite.
Nice catch, John!
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev
John Griffith wrote:
Yes, now that RC1 is tagged I'm planning to tag a new cinderclient
tomorrow. I'll be sure to send an announcement out as soon as it's up.
You mean, now that juno-3 is tagged ;) RC1 is still a few weeks and a
few dozens bugfixes away.
--
Thierry Carrez (ttx
again.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
technical debt that others have
mentioned as goals -- generally polishing what we have rather than
building out new things.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi
, to be honest.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
to come back? Or should we just purge those links?
It used to be a convenient way to graph bug stats from launchpad over
time. But I think the service died. So yes, links can probably be purged
now.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
in adding additional repositories. But I agree
there is little point in discussing splitting virt drivers (or anything
else, really) until the internal interface below that potential split is
fully cleaned up and it becomes an option.
--
Thierry Carrez (ttx
absolutely needs to be in Juno ? Feels
like a nice-to-have to me, and I fear we are past that point now.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
perspective case, having a project doing A+B
and a project doing A doesn't solve anything. So this affects the
decision we have to take next Tuesday...
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
seems like the right course of
action. We shouldn't graduate if there is any risk we would end up with
ZaqarV1 in Kilo, and then have to deprecate it for n cycles just because
it was shipped in the official release and therefore inherits its API
deprecation rules.
Regards,
--
Thierry Carrez (ttx
Duncan Thomas wrote:
On 12 September 2014 09:54, Thierry Carrez thie...@openstack.org wrote:
At this point, unless it's critical to the success of the release (like,
it completes a feature that is 99% there, or it increases consistency by
plugging a feature gap, or it fixes a potential
think this is wrong and think the design summit suggestion
website is a better way to do it, let me know why! If some programs
really can't stand the 'etherpad/IRC' approach I'll see how we can spin
up a limited instance.
Regards,
--
Thierry Carrez (ttx
/108609
I would say it's way too late at this point for a new driver in Juno. At
this point we should be focused on fixing what we already have, not add
more surface.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev
, as long as it's a public document and you can
link to it.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Russell Bryant wrote:
On 09/12/2014 07:37 AM, Thierry Carrez wrote:
If you think this is wrong and think the design summit suggestion
website is a better way to do it, let me know why! If some programs
really can't stand the 'etherpad/IRC' approach I'll see how we can spin
up a limited
it affects are quite affected, so I do feel it is time to
mention it.
I think those discussions could happen in a cross-project workshop.
We'll run 2 or 3 of those in parallel all day Tuesday, so there is
definitely room there.
--
Thierry Carrez (ttx
Mike Perez wrote:
On 14:24 Fri 05 Sep , Alex Meade wrote:
Hi Cinder Folks,
I would like to request a FFE for cinder pools support with the NetApp
drivers[1][2].
Looks like this is being reviewed now.
Looks like it merged, so I retroactively added it to RC1.
--
Thierry Carrez (ttx
responsible for smaller areas of code is the way to go.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
at this
point in the cycle. The risk/benefit ratio is too high, and focus should
be on bugfixing at this point.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
to be in. Having a clear channel
where all the gate liaisons hang out and all issues are discussed may go
a long way into establishing a team to work on that (rather than
continue to rely on the same set of willing individuals).
--
Thierry Carrez (ttx
day on Thursday to continue the discussions. I CCed Tom for more input
on that.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
of a disruption that would cause to them at this point.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
though, I just
need to add a new tag, which isn't much of a problem for me (since I use
a git based workflow).
The 1.4.0.0a5 is confusing... :(
According to Donald Stufft PEP 440 now allows 1.4.0.a5 now so we may not
need that extra 0 anymore.
--
Thierry Carrez (ttx
that Zaqar won't naturally mutate to support that use case.
The Zaqar team has shown great willingness to adapt in order to support
more use cases, but I guess there may be architectural design choices
that would just mean starting over ?
--
Thierry Carrez (ttx
). The
OpenStack project could be the big tent. We keep the TC, the ATCs
concepts the same.
That was a long answer, but then so was your original post :P
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
at
step 0, with projects banging on the TC door to become special, and
companies not allocating resources to anything that's not special.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org
Thierry Carrez wrote:
Radomir Dopieralski wrote:
I would like to request dependency freeze exceptions for the following
patches for Horizon:
https://review.openstack.org/#/c/121509/
https://review.openstack.org/#/c/122410/
and
https://review.openstack.org/#/c/113184/
They are all
.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
2015.1 (Kilo) release: Apr 23
L Design Summit: May 18-22
All milestones avoid known US holiday weekends. Let me know if I missed
something or if you see major issues with this proposal.
Regards,
--
Thierry Carrez (ttx)
kilo.pdf
Description: Adobe PDF document
dare pull a Joe Heck and disappear on us now.
:)
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
of the Technical Committee, and get the right to elect TC
members in return.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Robert Collins wrote:
On 19 September 2014 22:29, Thierry Carrez thie...@openstack.org wrote:
...
current Heat team is not really interested in maintaining them. What's
the point of being under the same program then ? And TripleO is not the
only way to deploy OpenStack, but its mere existence
Akihiro Motoki wrote:
I would like to request dependency freeze exceptions for
django-openstack-auth.
https://review.openstack.org/#/c/123101/
This arguably counts as an internal library. We are freezing those now
(well, last Friday was the deadline), so +1 on this one.
--
Thierry Carrez
Sean Dague wrote:
On 09/23/2014 02:56 AM, Thierry Carrez wrote:
Hi everyone,
Rather than waste a design summit session about it, I propose we review
the proposed Kilo release cycle schedule on the mailing-list. See
attached PDF for a picture of the proposal.
The hard date the proposal
Doug Hellmann wrote:
On Sep 23, 2014, at 5:18 AM, Thierry Carrez thie...@openstack.org wrote:
Devananda van der Veen wrote:
On Mon, Sep 22, 2014 at 2:27 PM, Doug Hellmann d...@doughellmann.com
wrote:
On Sep 22, 2014, at 5:10 PM, Devananda van der Veen
devananda@gmail.com wrote:
One
.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
and build reusable tooling for
everyone else to be able to handle releases. These are interesting times :)
Thanks for taking the time to read this!
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
://github.com/openstack/swift/tree/milestone-proposed
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
, and encourage people to hang
on to the extra rights associated with the duty.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
on, as opposed
to regularly review ANYTHING that comes up). Now if your -1s were
routinely ignored and you felt like this had a negative impact on the
security of the project, that would be a different story... But in the
present case, I think David makes the right decision.
--
Thierry Carrez (ttx
1 - 100 of 1930 matches
Mail list logo
