On Wed, Aug 13, 2014 at 5:13 AM, Mark McLoughlin <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 > > 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 room again. > > I'd love to hear more about this re-balancing idea. It sounds like we > have some concrete ideas here and we're saying they're not relevant to > this thread because they won't be an immediate solution? > > > This isn't just QA issues, it's a coordination issue on overall > > consistency across projects. Something that worked fine at 5 integrated > > projects, got strained at 9, and I think is completely untenable at 15. > > I can certainly relate to that from experience with Oslo. > > But if you take a concrete example - as more new projects emerge, it > became harder to get them all using oslo.messaging and using it > consistent ways. That's become a lot better with Doug's idea of Oslo > project delegates. > > But if we had not added those projects to the release, the only reason > that the problem would be more manageable is that the use of > oslo.messaging would effectively become a requirement for integration. > So, projects requesting integration have to take cross-project > responsibilities more seriously for fear their application would be > denied. > > That's a very sad conclusion. Our only tool for encouraging people to > take this cross-project issue is being accepted into the release and, > once achieved, the cross-project responsibilities aren't taken so > seriously? > > I don't think it's so bleak as that - given the proper support, > direction and tracking I think we're seeing in Oslo how projects will > play their part in getting to cross-project consistency. > > > I think one of the big issues with a large number of projects is that > > implications of implementation of one project impact others, but people > > don't always realize. Locally correct decisions for each project may not > > be globally correct for OpenStack. The GBP discussion, the Rally > > discussion, all are flavors of this. > > I think we need two things here - good examples of how these > cross-project initiatives can succeed so people can learn from them, and > for the initiatives themselves to be patiently lead by those whose goal > is a cross-project solution. > > It's hard work, absolutely no doubt. The point again, though, is that it > is possible to do this type of work in such a way that once a small > number of projects adopt the approach, most of the others will follow > quite naturally. > > If I was trying to get a consistent cross-project approach in a > particular area, the least of my concerns would be whether Ironic, > Marconi, Barbican or Designate would be willing to fall in line behind a > cross-project consensus. > > > People are frustrated in infra load, for instance. It's probably worth > > noting that the 'config' repo currently has more commits landed than any > > other project in OpenStack besides 'nova' in this release. It has 30% > > the core team size as Nova (http://stackalytics.com/?metric=commits). > > Yes, infra is an extremely busy project. I'm not sure I'd compare > infra/config commits to Nova commits in order to illustrate that, > though. > > Infra is a massive endeavor, it's as critical a part of the project as > any project in the integrated release, and like other "strategic > efforts" struggles to attract contributors from as diverse a number of > companies as the integrated projects. > > > So I do think we need to really think about what *must* be in OpenStack > > for it to be successful, and ensure that story is well thought out, and > > that the pieces which provide those features in OpenStack are clearly > > best of breed, so they are deployed in all OpenStack deployments, and > > can be counted on by users of OpenStack. > > I do think we try hard to think this through, but no doubt we need to do > better. Is this conversation concrete enough to really move our thinking > along sufficiently, though? > > > Because if every version of > > OpenStack deploys with a different Auth API (an example that's current > > but going away), we can't grow an ecosystem of tools around it. > > There's a nice concrete example, but it's going away? What's the best > current example to talk through? > > > This is organic definition of OpenStack through feedback with operators > > and developers on what's minimum needed and currently working well > > enough that people are happy to maintain it. And make that solid. > > > > Having a TC that is independently selected separate from the PTLs allows > > that group to try to make some holistic calls here. > > > > 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 with the state of things again * Marconi * Ceilometer Divert all cross project efforts from the following projects so we can focus 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 Yes: * All integrated projects that are not listed above > > Mark. > > > _______________________________________________ > 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
