On Wed, 27 Aug 2014, Angus Salkeld wrote:
I believe developers working on OpenStack work for companies that
really want this to happen. The developers also want their projects to
be well regarded. Just the way the problem is using framed is a bit
like you did above and this is very daunting for
On 08/26/2014 11:40 AM, Anne Gentle wrote:
On Mon, Aug 25, 2014 at 8:36 AM, Sean Dague s...@dague.net
mailto:s...@dague.net wrote:
On 08/20/2014 12:37 PM, Zane Bitter wrote:
On 11/08/14 05:24, Thierry Carrez wrote:
So the idea that being (and remaining) in the integrated
On Aug 27, 2014, at 8:47 AM, Sean Dague s...@dague.net wrote:
On 08/26/2014 11:40 AM, Anne Gentle wrote:
On Mon, Aug 25, 2014 at 8:36 AM, Sean Dague s...@dague.net
mailto:s...@dague.net wrote:
On 08/20/2014 12:37 PM, Zane Bitter wrote:
On 11/08/14 05:24, Thierry Carrez wrote:
So
On Aug 26, 2014, at 2:01 PM, Joe Gordon joe.gord...@gmail.com wrote:
On Wed, Aug 20, 2014 at 2:25 AM, Eoghan Glynn egl...@redhat.com wrote:
Additional cross-project resources can be ponied up by the large
contributor companies, and existing cross-project resources are not
On Aug 27, 2014, at 11:17 AM, Chris Dent chd...@redhat.com wrote:
On Wed, 27 Aug 2014, Doug Hellmann wrote:
For example, Matt helped me with an issue yesterday, and afterwards
I asked him to write up a few details about how he reached his
conclusion because he was moving fast enough that I
On Wed, 27 Aug 2014, Doug Hellmann wrote:
I have found it immensely helpful, for example, to have a written set
of the steps involved in creating a new library, from importing the
git repo all the way through to making it available to other projects.
Without those instructions, it would have
On Aug 27, 2014, at 1:30 PM, Chris Dent chd...@redhat.com wrote:
On Wed, 27 Aug 2014, Doug Hellmann wrote:
I have found it immensely helpful, for example, to have a written set
of the steps involved in creating a new library, from importing the
git repo all the way through to making it
On 08/25/2014 03:50 PM, Adam Lawson wrote:
I recognize I'm joining the discussion late but I've been following the
dialog fairly closely and want to offer my perspective FWIW. I have a
lot going through my head, not sure how to get it all out there so I'll
do a brain dump, get some feedback and
On Mon, Aug 25, 2014 at 8:36 AM, Sean Dague s...@dague.net wrote:
On 08/20/2014 12:37 PM, Zane Bitter wrote:
On 11/08/14 05:24, Thierry Carrez wrote:
So the idea that being (and remaining) in the integrated release should
also be judged on technical merit is a slightly different effort.
On Wed, Aug 20, 2014 at 2:25 AM, Eoghan Glynn egl...@redhat.com wrote:
Additional cross-project resources can be ponied up by the large
contributor companies, and existing cross-project resources are not
necessarily divertable on command.
Sure additional cross-project
On Wed, Aug 27, 2014 at 4:01 AM, Joe Gordon joe.gord...@gmail.com wrote:
On Wed, Aug 20, 2014 at 2:25 AM, Eoghan Glynn egl...@redhat.com wrote:
Additional cross-project resources can be ponied up by the large
contributor companies, and existing cross-project resources are not
On August 26, 2014, Anne Gentle wrote:
On Mon, Aug 25, 2014 at 8:36 AM, Sean Dague
s...@dague.netmailto:s...@dague.net wrote:
On 08/20/2014 12:37 PM, Zane Bitter wrote:
On 11/08/14 05:24, Thierry Carrez wrote:
So the idea that being (and remaining) in the integrated release should
also be
On 08/20/2014 12:37 PM, Zane Bitter wrote:
On 11/08/14 05:24, Thierry Carrez wrote:
So the idea that being (and remaining) in the integrated release should
also be judged on technical merit is a slightly different effort. It's
always been a factor in our choices, but like Devananda says, it's
I recognize I'm joining the discussion late but I've been following the
dialog fairly closely and want to offer my perspective FWIW. I have a lot
going through my head, not sure how to get it all out there so I'll do a
brain dump, get some feedback and apologize in advance.
One the things I like
On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes jaypi...@gmail.com wrote:
On 08/19/2014 11:28 PM, Robert Collins wrote:
On 20 August 2014 02:37, Jay Pipes jaypi...@gmail.com wrote:
...
I'd like to see more unification of implementations in TripleO - but I
still believe our basic principle of
Excerpts from Michael Chapman's message of 2014-08-21 23:30:44 -0700:
On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes jaypi...@gmail.com wrote:
On 08/19/2014 11:28 PM, Robert Collins wrote:
On 20 August 2014 02:37, Jay Pipes jaypi...@gmail.com wrote:
...
I'd like to see more unification
On 08/22/2014 01:30 AM, Michael Chapman wrote:
On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:
On 08/19/2014 11:28 PM, Robert Collins wrote:
On 20 August 2014 02:37, Jay Pipes jaypi...@gmail.com
On 21 August 2014 19:39, gordon chung g...@live.ca wrote:
from the pov of a project that seems to be brought up constantly and maybe
it's my naivety, i don't really understand the fascination with branding and
the stigma people have placed on non-'openstack'/stackforge projects. it
can't be a
which require ip plan/legal approval on a per project basis.
Regards
sean
-Original Message-
From: Duncan Thomas [mailto:duncan.tho...@gmail.com]
Sent: Friday, August 22, 2014 4:39 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all
On Fri, Aug 22, 2014 at 9:51 PM, Sean Dague s...@dague.net wrote:
On 08/22/2014 01:30 AM, Michael Chapman wrote:
On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:
On 08/19/2014 11:28 PM, Robert Collins wrote:
On 20 August
Comment inline.
On Aug 22, 2014, at 10:13 AM, Michael Chapman wop...@gmail.com wrote:
On Fri, Aug 22, 2014 at 9:51 PM, Sean Dague s...@dague.net wrote:
On 08/22/2014 01:30 AM, Michael Chapman wrote:
On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes jaypi...@gmail.com
It may be easier for you, but it certainly isn't inside big companies,
e.g. HP have pretty broad approvals for contributing to (official)
openstack projects, where as individual approval may be needed to
contribute to none-openstack projects.
i was referring to a company bigger than hp...
On 08/22/2014 02:13 PM, Michael Chapman wrote:
We try to target puppet module master at upstream OpenStack master, but
without CI/CD we fall behind. The missing piece is building packages and
creating a local repo before doing the puppet run, which I'm working on
slowly as I want a single
On 08/20/2014 09:54 PM, Clint Byrum wrote:
Excerpts from Jay Pipes's message of 2014-08-20 14:53:22 -0700:
On 08/20/2014 05:06 PM, Chris Friesen wrote:
On 08/20/2014 07:21 AM, Jay Pipes wrote:
Hi Thierry, thanks for the reply. Comments inline. :)
On 08/20/2014 06:32 AM, Thierry Carrez wrote:
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
Jay Pipes wrote:
I don't believe the Programs are needed, as they are currently
structured. I don't really believe they serve any good purposes, and
actually serve to solidify positions of power, slanted towards existing
power centers, which is antithetical to a meritocratic community.
Let me
On 08/20/2014 02:37 PM, Jay Pipes wrote:
On 08/20/2014 11:41 AM, Zane Bitter wrote:
On 19/08/14 10:37, Jay Pipes wrote:
By graduating an incubated project into the integrated release, the
Technical Committee is blessing the project as the OpenStack way to do
some thing. If there are projects
On Thu, 21 Aug 2014, Sean Dague wrote:
By blessing one team what we're saying is all the good ideas pool for
tackling this hard problem can only come from that one team.
This is a big part of this conversation that really confuses me. Who is
that one team?
I don't think it is that team that
On 08/21/2014 07:58 AM, Chris Dent wrote:
On Thu, 21 Aug 2014, Sean Dague wrote:
By blessing one team what we're saying is all the good ideas pool for
tackling this hard problem can only come from that one team.
This is a big part of this conversation that really confuses me. Who is
that one
On 08/20/2014 11:54 PM, Clint Byrum wrote:
Excerpts from Jay Pipes's message of 2014-08-20 14:53:22 -0700:
On 08/20/2014 05:06 PM, Chris Friesen wrote:
On 08/20/2014 07:21 AM, Jay Pipes wrote:
...snip
We already run into issues with something as basic as competing SQL
databases.
If the TC
On Thu, Aug 21, 2014 at 4:09 AM, Thierry Carrez thie...@openstack.org wrote:
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
Excerpts from Duncan Thomas's message of 2014-08-21 09:21:06 -0700:
On 21 August 2014 14:27, Jay Pipes jaypi...@gmail.com wrote:
Specifically for Triple-O, by making the Deployment program == Triple-O, the
TC has picked the disk-image-based deployment of an undercloud design as The
On 20/08/14 15:37, Jay Pipes wrote:
For example, everyone agrees that Ceilometer has
room for improvement, but any implication that the Ceilometer is not
interested in or driving towards those improvements (because of NIH or
whatever) is, as has been pointed out, grossly unfair to the Ceilometer
The point I've been making is
that by the TC continuing to bless only the Ceilometer project as the
OpenStack Way of Metering, I think we do a disservice to our users by
picking a winner in a space that is clearly still unsettled.
can we avoid using the word 'blessed' -- it's extremely
On 08/21/2014 02:39 PM, gordon chung wrote:
The point I've been making is
that by the TC continuing to bless only the Ceilometer project as the
OpenStack Way of Metering, I think we do a disservice to our users by
picking a winner in a space that is clearly still unsettled.
can we avoid
Excerpts from David Kranz's message of 2014-08-21 12:45:05 -0700:
On 08/21/2014 02:39 PM, gordon chung wrote:
The point I've been making is
that by the TC continuing to bless only the Ceilometer project as the
OpenStack Way of Metering, I think we do a disservice to our users by
On 08/21/2014 04:12 PM, Clint Byrum wrote:
Excerpts from David Kranz's message of 2014-08-21 12:45:05 -0700:
On 08/21/2014 02:39 PM, gordon chung wrote:
The point I've been making is
that by the TC continuing to bless only the Ceilometer project as the
OpenStack Way of Metering, I think we do
OpenStack
(919) 543-0646
Internet: bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680
From: Clint Byrum cl...@fewbar.com
To: openstack-dev openstack-dev@lists.openstack.org,
Date: 08/21/2014 04:13 PM
Subject:Re: [openstack-dev] [all] The future of the integrated
I think we can't throw Ceilometer and Triple-O in the same discussion:
they're two separate issues IMHO, with different root causes and
therefore different solutions.
On 08/21/2014 06:27 AM, Jay Pipes wrote:
The point I've been making is
that by the TC continuing to bless only the Ceilometer
Additional cross-project resources can be ponied up by the large
contributor companies, and existing cross-project resources are not
necessarily divertable on command.
Sure additional cross-project resources can and need to be ponied up, but I
am doubtful that will be enough.
Eoghan Glynn wrote:
[...]
And which cross-project concern do you think is most strained by the
current set of projects in the integrated release? Is it:
* QA
* infra
* release management
* oslo
* documentation
* stable-maint
or something else?
Good question.
IMHO QA, Infra and
Jay Pipes wrote:
[...]
If either of the above answers is NO, then I believe the Technical
Committee should recommend that the integrated project be removed from
the integrated release.
HOWEVER, I *also* believe that the previously-integrated project should
not just be cast away back to
Hi Thierry, thanks for the reply. Comments inline. :)
On 08/20/2014 06:32 AM, Thierry Carrez wrote:
Jay Pipes wrote:
[...] If either of the above answers is NO, then I believe the
Technical Committee should recommend that the integrated project be
removed from the integrated release.
HOWEVER,
On 19/08/14 10:37, Jay Pipes wrote:
By graduating an incubated project into the integrated release, the
Technical Committee is blessing the project as the OpenStack way to do
some thing. If there are projects that are developed *in the OpenStack
ecosystem* that are actively being developed to
On 11/08/14 05:24, Thierry Carrez wrote:
So the idea that being (and remaining) in the integrated release should
also be judged on technical merit is a slightly different effort. It's
always been a factor in our choices, but like Devananda says, it's more
difficult than just checking a number of
On 08/20/2014 11:41 AM, Zane Bitter wrote:
On 19/08/14 10:37, Jay Pipes wrote:
By graduating an incubated project into the integrated release, the
Technical Committee is blessing the project as the OpenStack way to do
some thing. If there are projects that are developed *in the OpenStack
On 08/20/2014 07:21 AM, Jay Pipes wrote:
Hi Thierry, thanks for the reply. Comments inline. :)
On 08/20/2014 06:32 AM, Thierry Carrez wrote:
If we want to follow your model, we probably would have to dissolve
programs as they stand right now, and have blessed categories on one
side, and teams
On 08/20/2014 05:06 PM, Chris Friesen wrote:
On 08/20/2014 07:21 AM, Jay Pipes wrote:
Hi Thierry, thanks for the reply. Comments inline. :)
On 08/20/2014 06:32 AM, Thierry Carrez wrote:
If we want to follow your model, we probably would have to dissolve
programs as they stand right now, and
On Thu, Aug 21, 2014 at 2:37 AM, Zane Bitter zbit...@redhat.com wrote:
On 11/08/14 05:24, Thierry Carrez wrote:
So the idea that being (and remaining) in the integrated release should
also be judged on technical merit is a slightly different effort. It's
always been a factor in our choices,
Excerpts from Robert Collins's message of 2014-08-18 23:41:20 -0700:
On 18 August 2014 09:32, Clint Byrum cl...@fewbar.com wrote:
I can see your perspective but I don't think its internally consistent...
Here's why folk are questioning Ceilometer:
Nova is a set of tools to abstract
Excerpts from Jay Pipes's message of 2014-08-20 14:53:22 -0700:
On 08/20/2014 05:06 PM, Chris Friesen wrote:
On 08/20/2014 07:21 AM, Jay Pipes wrote:
Hi Thierry, thanks for the reply. Comments inline. :)
On 08/20/2014 06:32 AM, Thierry Carrez wrote:
If we want to follow your model, we
On 18 August 2014 09:32, Clint Byrum cl...@fewbar.com wrote:
I can see your perspective but I don't think its internally consistent...
Here's why folk are questioning Ceilometer:
Nova is a set of tools to abstract virtualization implementations.
With a big chunk of local things - local image
On 08/14/2014 01:08 AM, Devananda van der Veen wrote:
On Wed, Aug 13, 2014 at 5:37 AM, Mark McLoughlin mar...@redhat.com
mailto:mar...@redhat.com wrote:
On Fri, 2014-08-08 at 15:36 -0700, Devananda van der Veen wrote:
On Tue, Aug 5, 2014 at 10:02 AM, Monty Taylor mord...@inaugust.com
On 08/14/2014 03:38 PM, Russell Bryant wrote:
On 08/14/2014 09:21 AM, Devananda van der Veen wrote:
On Aug 14, 2014 2:04 AM, Eoghan Glynn egl...@redhat.com
mailto:egl...@redhat.com wrote:
Letting the industry field-test a project and feed their experience
back into the community is a slow
On 08/13/2014 08:41 PM, Joe Gordon wrote:
On Wed, Aug 13, 2014 at 5:13 AM, Mark McLoughlin mar...@redhat.com
mailto:mar...@redhat.com wrote:
On Thu, 2014-08-07 at 09:30 -0400, Sean Dague wrote:
While I definitely think re-balancing our quality responsibilities
back
On 8/18/2014 9:27 AM, Thierry Carrez wrote:
Clint Byrum wrote:
Here's why folk are questioning Ceilometer:
Nova is a set of tools to abstract virtualization implementations.
Neutron is a set of tools to abstract SDN/NFV implementations.
Cinder is a set of tools to abstract block-device
Caution: words below may cause discomfort. I ask that folks read *all*
of my message before reacting to any piece of it. Thanks!
On 08/19/2014 02:41 AM, Robert Collins wrote:
On 18 August 2014 09:32, Clint Byrum cl...@fewbar.com wrote:
I can see your perspective but I don't think its
On 08/19/2014 07:37 AM, Jay Pipes wrote:
All of these projects should be able to live in the Program, in the
openstack/ code namespace, for as long as the project is actively
developed, and let the contributor communities in these competing
projects *naturally* work to do any of the following:
On 20 August 2014 02:37, Jay Pipes jaypi...@gmail.com wrote:
...
I'd like to see more unification of implementations in TripleO - but I
still believe our basic principle of using OpenStack technologies that
already exist in preference to third party ones is still sound, and
offers substantial
On 20 August 2014 15:28, Robert Collins robe...@robertcollins.net wrote:
I think you mean it 'can be argued'... ;). And I'd be happy if folk in
those communities want to join in the deployment program and have code
repositories in openstack/. To date, none have asked.
Sorry, that was
Clint Byrum wrote:
Here's why folk are questioning Ceilometer:
Nova is a set of tools to abstract virtualization implementations.
Neutron is a set of tools to abstract SDN/NFV implementations.
Cinder is a set of tools to abstract block-device implementations.
Trove is a set of tools to
On Mon, 2014-08-18 at 14:23 +0200, Thierry Carrez wrote:
Clint Byrum wrote:
Here's why folk are questioning Ceilometer:
Nova is a set of tools to abstract virtualization implementations.
Neutron is a set of tools to abstract SDN/NFV implementations.
Cinder is a set of tools to abstract
On Wed, Aug 13, 2014 at 3:29 PM, Doug Hellmann d...@doughellmann.com
wrote:
On Aug 13, 2014, at 4:08 PM, Matthew Treinish mtrein...@kortar.org
wrote:
On Wed, Aug 13, 2014 at 03:43:21PM -0400, Eoghan Glynn wrote:
Divert all cross project efforts from the following projects so we
can
On Fri, Aug 15, 2014 at 3:01 PM, Joe Gordon joe.gord...@gmail.com wrote:
On Thu, Aug 14, 2014 at 4:02 PM, Eoghan Glynn egl...@redhat.com wrote:
Additional cross-project resources can be ponied up by the large
contributor companies, and existing cross-project resources are not
On Fri, Aug 15, 2014 at 7:17 PM, Sandy Walsh sandy.wa...@rackspace.com
wrote:
I recently suggested that the Ceilometer API (and integration tests) be
separated from the implementation (two repos) so others might plug in a
different implementation while maintaining compatibility, but that
On 08/17/2014 05:11 AM, Stan Lagun wrote:
On Fri, Aug 15, 2014 at 7:17 PM, Sandy Walsh sandy.wa...@rackspace.com
mailto:sandy.wa...@rackspace.com wrote:
I recently suggested that the Ceilometer API (and integration tests)
be separated from the implementation (two repos) so others might
Hello all,
As a Ceilometer's core, I'd like to add my 0.02$.
During previous discussions it was mentioned several projects which were
started or continue to be developed after Ceilometer became integrated. The
main question I'm thinking of is why it was impossible to contribute into
existing
Here's why folk are questioning Ceilometer:
Nova is a set of tools to abstract virtualization implementations.
Neutron is a set of tools to abstract SDN/NFV implementations.
Cinder is a set of tools to abstract block-device implementations.
Trove is a set of tools to simplify consumption of
On Fri, 15 Aug 2014, Sandy Walsh wrote:
I recently suggested that the Ceilometer API (and integration tests)
be separated from the implementation (two repos) so others might plug
in a different implementation while maintaining compatibility, but
that wasn't well received.
Personally, I'd like
On 8/16/2014 10:09 AM, Chris Dent wrote:
On Fri, 15 Aug 2014, Sandy Walsh wrote:
I recently suggested that the Ceilometer API (and integration tests)
be separated from the implementation (two repos) so others might plug
in a different implementation while maintaining compatibility, but
that
On 8/14/2014 6:42 PM, Doug Hellmann wrote:
On Aug 14, 2014, at 4:41 PM, Joe Gordon
joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote:
On Wed, Aug 13, 2014 at 12:24 PM, Doug Hellmann
d...@doughellmann.commailto:d...@doughellmann.com wrote:
On Aug 13, 2014, at 3:05 PM, Eoghan Glynn
But, if someone asked me what they should use for metering today,
I'd point them towards Monasca in a heartbeat.
FWIW my view is that Monasca is an interesting emerging project, with a
team accreting around it that seems to be interested in collaboration.
We've had ongoing discussions with
On Fri, Aug 15, 2014 at 8:17 AM, Sandy Walsh sandy.wa...@rackspace.com
wrote:
On 8/14/2014 6:42 PM, Doug Hellmann wrote:
On Aug 14, 2014, at 4:41 PM, Joe Gordon joe.gord...@gmail.com wrote:
On Wed, Aug 13, 2014 at 12:24 PM, Doug Hellmann d...@doughellmann.com
wrote:
On Aug 13,
On Thu, Aug 14, 2014 at 4:02 PM, Eoghan Glynn egl...@redhat.com wrote:
Additional cross-project resources can be ponied up by the large
contributor companies, and existing cross-project resources are not
necessarily divertable on command.
Sure additional cross-project resources can
On Thu, Aug 14, 2014 at 4:02 PM, Eoghan Glynn egl...@redhat.com wrote:
Additional cross-project resources can be ponied up by the large
contributor companies, and existing cross-project resources are not
necessarily divertable on command.
Sure additional cross-project resources can
On Aug 14, 2014 2:04 AM, Eoghan Glynn egl...@redhat.com wrote:
Letting the industry field-test a project and feed their experience
back into the community is a slow process, but that is the best
measure of a project's success. I seem to recall this being an
implicit expectation a few
On Aug 13, 2014, at 5:07 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Wed, Aug 13, 2014 at 12:55:48PM +0100, Steven Hardy wrote:
On Wed, Aug 13, 2014 at 11:42:52AM +0100, Daniel P. Berrange wrote:
On Thu, Aug 07, 2014 at 03:56:04AM -0700, Jay Pipes wrote:
By ignoring stable branches,
On Wed, Aug 13, 2014 at 12:24 PM, Doug Hellmann d...@doughellmann.com
wrote:
On Aug 13, 2014, at 3:05 PM, Eoghan Glynn egl...@redhat.com wrote:
At the end of the day, that's probably going to mean saying No to more
things. Everytime I turn around everyone wants the TC to say No to
On Aug 14, 2014, at 4:41 PM, Joe Gordon joe.gord...@gmail.com wrote:
On Wed, Aug 13, 2014 at 12:24 PM, Doug Hellmann d...@doughellmann.com wrote:
On Aug 13, 2014, at 3:05 PM, Eoghan Glynn egl...@redhat.com wrote:
At the end of the day, that's probably going to mean saying No to
Additional cross-project resources can be ponied up by the large
contributor companies, and existing cross-project resources are not
necessarily divertable on command.
Sure additional cross-project resources can and need to be ponied up, but I
am doubtful that will be enough.
OK, so
One thing I'm not seeing shine through in this discussion of slots is
whether any notion of individual cores, or small subsets of the core
team with aligned interests, can champion blueprints that they have
a particular interest in.
I think that's because we've focussed in this
On 08/13/2014 04:05 AM, Michael Still wrote:
On Wed, Aug 13, 2014 at 4:26 AM, Eoghan Glynn egl...@redhat.com wrote:
It seems like this is exactly what the slots give us, though. The core
review
team picks a number of slots indicating how much work they think they can
actually do (less than
Nikola Đipanov wrote:
While I agree with motivation for this - setting the expectations, I
fail to see how this is different to what the Swift guys seem to be
doing apart from more red tape.
It's not different imho. It's just that nova as significantly more
features being thrown at it, so the
Rochelle.RochelleGrober wrote:
[...]
So, with all that prologue, here is what I propose (and please consider
proposing your improvements/changes to it). I would like to see for Kilo:
- IRC meetings and mailing list meetings beginning with Juno release and
continuing through the summit
On Mon, Aug 11, 2014 at 10:30:12PM -0700, Joe Gordon wrote:
On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery mest...@mestery.com wrote:
I really like this idea, as Michael and others alluded to in above, we
are
attempting to set cycle goals for Kilo in Nova. but I think it is worth
doing
On 08/07/2014 12:56 PM, Jay Pipes wrote:
On 08/07/2014 02:12 AM, Kashyap Chamarthy wrote:
On Thu, Aug 07, 2014 at 07:10:23AM +1000, Michael Still wrote:
On Wed, Aug 6, 2014 at 2:03 AM, Thierry Carrez
thie...@openstack.org wrote:
We seem to be unable to address some key issues in the software
On Thu, Aug 07, 2014 at 03:56:04AM -0700, Jay Pipes wrote:
On 08/07/2014 02:12 AM, Kashyap Chamarthy wrote:
On Thu, Aug 07, 2014 at 07:10:23AM +1000, Michael Still wrote:
On Wed, Aug 6, 2014 at 2:03 AM, Thierry Carrez thie...@openstack.org
wrote:
We seem to be unable to address some key
On Tue, 2014-08-05 at 18:03 +0200, Thierry Carrez wrote:
Hi everyone,
With the incredible growth of OpenStack, our development community is
facing complex challenges. How we handle those might determine the
ultimate success or failure of OpenStack.
With this cycle we hit new limits in our
On Wed, Aug 13, 2014 at 11:42:52AM +0100, Daniel P. Berrange wrote:
On Thu, Aug 07, 2014 at 03:56:04AM -0700, Jay Pipes wrote:
On 08/07/2014 02:12 AM, Kashyap Chamarthy wrote:
On Thu, Aug 07, 2014 at 07:10:23AM +1000, Michael Still wrote:
On Wed, Aug 6, 2014 at 2:03 AM, Thierry Carrez
On Wed, Aug 13, 2014 at 12:55:48PM +0100, Steven Hardy wrote:
On Wed, Aug 13, 2014 at 11:42:52AM +0100, Daniel P. Berrange wrote:
On Thu, Aug 07, 2014 at 03:56:04AM -0700, Jay Pipes wrote:
That said, I entirely agree with you and wish efforts to stabilize would
take precedence over
On Thu, 2014-08-07 at 09:30 -0400, Sean Dague wrote:
While I definitely think re-balancing our quality responsibilities back
into the projects will provide an overall better release, I think it's
going to take a long time before it lightens our load to the point where
we get more breathing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 13/08/14 14:07, Daniel P. Berrange wrote:
On Wed, Aug 13, 2014 at 12:55:48PM +0100, Steven Hardy wrote:
On Wed, Aug 13, 2014 at 11:42:52AM +0100, Daniel P. Berrange
wrote:
On Thu, Aug 07, 2014 at 03:56:04AM -0700, Jay Pipes wrote:
That said,
On 08/12/2014 10:05 PM, Michael Still wrote:
there are hundreds of proposed features for
Juno, nearly 100 of which have been accepted. However, we're kidding
ourselves if we think we can land 100 blueprints in a release cycle.
FWIW, I think this is actually huge improvement from previous
On Fri, 2014-08-08 at 15:36 -0700, Devananda van der Veen wrote:
On Tue, Aug 5, 2014 at 10:02 AM, Monty Taylor mord...@inaugust.com wrote:
Yes.
Additionally, and I think we've been getting better at this in the 2 cycles
that we've had an all-elected TC, I think we need to learn how to
On Tue, 2014-08-12 at 14:26 -0400, Eoghan Glynn wrote:
It seems like this is exactly what the slots give us, though. The core
review
team picks a number of slots indicating how much work they think they can
actually do (less than the available number of blueprints), and then
blueprints
On Wed, Aug 13, 2014 at 5:15 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Mon, Aug 11, 2014 at 10:30:12PM -0700, Joe Gordon wrote:
On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery mest...@mestery.com wrote:
I really like this idea, as Michael and others alluded to in above, we
are
On Tue, 2014-08-12 at 14:12 -0700, Joe Gordon wrote:
Here is the full nova proposal on Blueprint in Kilo: Runways and
Project Priorities
https://review.openstack.org/#/c/112733/
http://docs-draft.openstack.org/33/112733/4/check/gate-nova-docs/5f38603/doc/build/html/devref/runways.html
On 08/13/2014 08:52 AM, Mark McLoughlin wrote:
On Tue, 2014-08-12 at 14:26 -0400, Eoghan Glynn wrote:
It seems like this is exactly what the slots give us, though. The core
review
team picks a number of slots indicating how much work they think they can
actually do (less than the available
On Wed, Aug 13, 2014 at 09:11:26AM -0400, Russell Bryant wrote:
On 08/13/2014 08:52 AM, Mark McLoughlin wrote:
On Tue, 2014-08-12 at 14:26 -0400, Eoghan Glynn wrote:
It seems like this is exactly what the slots give us, though. The core
review
team picks a number of slots indicating
It seems like this is exactly what the slots give us, though. The core
review
team picks a number of slots indicating how much work they think they can
actually do (less than the available number of blueprints), and then
blueprints queue up to get a slot based on priorities and
1 - 100 of 176 matches
Mail list logo
