← Back to team overview

openstack-poc team mailing list archive

Re: Revisit project autonomy / project philosophy discussion

 

On Jul 12, 2011, at 12:45 PM, Jay Pipes wrote:
> 
> 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.

This doesn't mean different "places", ie toolsets. Different "roles". Openstack should be focused on doing what is possible to encourage getting these projects into production: large-scale QA, defining the "Openstack vision", and visibility to the community for roadmaps, bugs, and advocacy. The big-picture things rather than toolset-level choices.

> 
> 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.

Absolutely agree. This is the issue that needs to be resolved. I wouldn't have worded it exactly like you did here, but this does get to the heart of the issue, and it's why we're talking about this in the first place.

As a side-note here, I'd really like to avoid an "us vs them" mentality for this debate. Let's please discuss the arguments based on their merits rather than framing things in a dev team A vs dev team B way.

> 
> If we only used the tools that the Swift team preferred, would you
> really take issue with any of this?

The right answer for the wrong reasons may still be the wrong answer. Using foobar hosting is not the important decision to me. The important issue is whether a project can use foobar hosting or not, at its own discretion. 

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Follow ups

References