On Tue, Jul 12, 2011 at 12:23 PM, John Dickinson <john.dickin...@rackspace.com> wrote: > I'm starting a separate thread here so that we can keep the discussions clear > in our minds. > > It seems that there is some misunderstanding on what was discussed and > decided a couple of weeks ago. A decision was made, but what that even means > still seems unclear. > > I'm not sure that anyone is advocating for complete project autonomy in all > respects. (I say this as the person who seems to be the strongest advocate > for autonomy--please correct me if I'm wrong here.) With no guidelines or > requirements on projects, Openstack ceases to mean much at all. That being > said, I do think that projects should have a great deal of latitude. > > I believe OpenStack should should provide: > • A common unifying vision for the group that each individual project > must agree to > • Central place to go for: > • OpenStack releases. > • OpenStack documentation. > • Bug reporting. > • Roadmaps. > • Managing OpenStack packaging of projects. > > Everything else should be guidelines and support in implementation if those > guidelines are desired. Such as: > • Code hosting > • Bug tracking > • Roadmap planning > • Project releases and packaging
So, you'd have bug *reporting* in one place and bug *tracking* in another? And you'd have roadmaps displayed in one place, but roadmap *planning* in another? That sounds like a terrible idea to me. Again, this goes back to the fundamental philosophical difference; the Swift team feels like OpenStack is a set of loosely affiliated projects that happen to have a "unifying vision for the group" (whatever that means). Others, including myself, view the OpenStack project as a Cloud platform that has individual projects, some of which may be individually installed as stand-alone components, but that are meant to function in an integrated and cohesive way. I think that the focus of the OpenStack project should be the *harmonious interaction of the various OpenStack subprojects*. To do this, we need subprojects to agree on a set of common tools and, importantly, development and release processes that allow a common continuous deployment and integration testing platform to work smoothly. We've already said that we're willing to support a vetted set of options for code hosting. Do we need to vote on that again? If we only used the tools that the Swift team preferred, would you really take issue with any of this? Finally, I personally view the promise of OpenStack as an open source project where the community has a clear, agreed upon way of contributing to the project as a whole and to the individual subprojects. Having every subproject doing their own thing from a community contribution perspective makes cross-project contribution difficult and potentially annoying to contributors. While I understand that the Swift code base is at a different stage in its life than the other subprojects and that the Swift team looks with disdain at the "simple projects" like Glance (Chuck's words, not mine), the fact is that there is an openness to contribution that seems to exist with Nova, Glance, and now Keystone that does not exist in the same way for either Swift or Burrow. I strongly feel that this is not by accident. It would be great if the contributor community at large felt welcomed to contribute to all of the subprojects at once and did not have to re-learn a different dev process or toolchain each time they did. To take this point further, I would be happier if we were to fully separate the agreement and development of the individual endpoint APIs from the implementation of those endpoints. That way, contributors interested in implementing existing APIs in a completely different way can do so in an open and community-oriented manner and the PPB can vote for incubation competing implementations of existing APIs. Just my two cents, -jay _______________________________________________ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp