openstack-poc team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Tue, Jul 12, 2011 at 12:23 PM, John Dickinson
<john.dickinson@xxxxxxxxxxxxx> 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