openstack-poc team mailing list archive

[John Dickinson <john.dickinson@xxxxxxxxxxxxx>]

On Jul 12, 2011, at 2:43 PM, Jay Pipes wrote:

> On Tue, Jul 12, 2011 at 3:34 PM, Soren Hansen <soren@xxxxxxxxxxx> wrote:
>> 2011/7/12 John Dickinson <john.dickinson@xxxxxxxxxxxxx>:
>>> 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.
>> 
>> I still have no clue what this means. Can you elaborate?
> 
> I'll give it a shot. John, correct me if I'm off base. This helps me
> understand the other point of view...
> 
> I think what John is making the distinction between is that reporting
> bugs and displaying a roadmap for OpenStack, the set of related
> projects, should be in one place, and the focus of people working on
> "OpenStack" (as opposed to the individual projects themselves) should
> be focusing only on large-scale QA, while the individual projects
> should be free to use whatever tools work best for them and not be too
> concerned about what the OpenStack project (the whole thing) uses or
> needs.

Close. The Openstack entity (which is essentially the PPB) should be concerned with doing what is necessary to ensure the component projects fulfill the openstack vision/mission statement. For example, if the mission of openstack is to provide software that runs well at large scale, openstack should provide some sort of large-scale QA process to encourage adoption.

The component projects should be very much concerned about the needs of the group as a whole--the projects must adopt and support the vision/mission when they join the project. For example, if the openstack entity determines that there needs to be a common place to see bugs and roadmaps, projects should integrate with that. Integrating doesn't mean that the projects must adopt a particular toolset, but if they don't they need to provide the information to those tools. (See the end of my original email for more concrete examples of this.)

In a sense, the openstack project-as-a-whole (ie today effectively our Ubuntu packaging) becomes another project along side the other core projects. Each project then, including the packaging project, make their own decisions based on their own needs. (As a side note, this would provide a framework which would easily allow other non-Ubuntu packaging projects to be supported.) The community as a whole (ie the PPB) set the tone and guidelines, and the projects work together to get stuff done, choosing their own best practices based on their own needs and collaborating where necessary and beneficial.

--John

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