openstack-poc team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

+1

As for bug reporting, I'm imaginging a common "OpenStack" bug
reporting location, possibly the parent Launchpad project if that
is supported. The common reporting location can also have links
to specific projects if it can be isolated as well (for devs/more
advanced users). There may be some duplication and loose coupling, but
I don't imagine it will be much of an issue. The projects will just
need to keep a detailed list of implemented features and fixed bugs
with whatever system they choose instead of Launchpad automatically
providing this.

-Eric

On Tue, Jul 12, 2011 at 11:23:19AM -0500, John Dickinson 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, as long as a project meets the dictated rules in the first section, it shouldn't matter how they accomplish it in the second section. If a project team really really wants to use Bitkeeper and Bugzilla to manage their project, that should be fine, even if they have to manually update the OpenStack centralized bug reports and roadmaps. If they tend to only use Red Hat in their work, and therefore their project releases and packaging, that should be fine as long as they update the OpenStack packaging for the OpenStack releases.
> 
> I believe this sort of autonomy provides for differences in project teams, project lifecycles, and reduces barriers for new projects to join.



> _______________________________________________
> Mailing list: https://launchpad.net/~openstack-poc
> Post to     : openstack-poc@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack-poc
> More help   : https://help.launchpad.net/ListHelp