On Tue, Jul 12, 2011 at 4:29 PM, John Dickinson <[email protected]> wrote: > On Jul 12, 2011, at 2:43 PM, Jay Pipes wrote: >> On Tue, Jul 12, 2011 at 3:34 PM, Soren Hansen <[email protected]> wrote: >>> 2011/7/12 John Dickinson <[email protected]>: >>>> 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.
OK, that explains things a bit more clearly. I don't agree, mind you, but I better understand your point of view. Thanks, John. -jay _______________________________________________ Mailing list: https://launchpad.net/~openstack-poc Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
