[openstack-dev] [all] The future of the integrated release
joe.gordon0 at gmail.com
Thu Aug 14 20:41:34 UTC 2014
On Wed, Aug 13, 2014 at 12:24 PM, Doug Hellmann <doug at doughellmann.com>
> On Aug 13, 2014, at 3:05 PM, Eoghan Glynn <eglynn at 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
> >>> things, just not to their particular thing. :) Which is human nature.
> >>> But I think if we don't start saying No to more things we're going to
> >>> end up with a pile of mud that no one is happy with.
> >> That we're being so abstract about all of this is frustrating. I get
> >> that no-one wants to start a flamewar, but can someone be concrete about
> >> what they feel we should say 'no' to but are likely to say 'yes' to?
> >> I'll bite, but please note this is a strawman.
> >> No:
> >> * Accepting any more projects into incubation until we are comfortable
> >> the state of things again
> >> * Marconi
> >> * Ceilometer
> > Well -1 to that, obviously, from me.
> > Ceilometer is on track to fully execute on the gap analysis coverage
> > plan agreed with the TC at the outset of this cycle, and has an active
> > plan in progress to address architectural debt.
> Yes, there seems to be an attitude among several people in the community
> that the Ceilometer team denies that there are issues and refuses to work
> on them. Neither of those things is the case from our perspective.
> Can you be more specific about the shortcomings you see in the project
> that aren’t being addressed?
Once again, this is just a strawman.
I'm just not sure OpenStack has 'blessed' the best solution out there.
- Successfully passed the challenge of being adopted by 3 related
projects which have agreed to join or use ceilometer:
Stacktach seems to still be under active development (
http://git.openstack.org/cgit/stackforge/stacktach/log/), is used by
rackspace in production and from everything I hear is more mature then
> >> Divert all cross project efforts from the following projects so we can
> >> our cross project resources. Once we are in a bitter place we can
> expand our
> >> cross project resources to cover these again. This doesn't mean removing
> >> anything.
> >> * Sahara
> >> * Trove
> >> * Tripleo
> > You write as if cross-project efforts are both of fixed size and
> > amenable to centralized command & control.
> > Neither of which is actually the case, IMO.
> > 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.
> What “cross-project efforts” are we talking about? The liaison program in
> Oslo has been a qualified success so far. Would it make sense to extend
> that to other programs and say that each project needs at least one
> designated QA, Infra, Doc, etc. contact?
> >> Yes:
> >> * All integrated projects that are not listed above
> > And what of the other pending graduation request?
> > Cheers,
> > Eoghan
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev