[openstack-dev] Launchpad bug tracker defects (was: Proposal oslo.db lib)

Clint Byrum clint at fewbar.com
Sat Aug 17 04:57:58 UTC 2013


Excerpts from Thierry Carrez's message of 2013-08-16 13:55:46 -0700:
> Jay Pipes wrote:
> >>>> Are you going to create a separate Launchpad project for the library
> >>>> and track bugs against it separately? Or are you going to use the oslo
> >>>> project in Launchpad for that?
> >>>
> >>> At the moment all of the oslo.* projects are just grouped under the
> >>> overall Oslo project in LP.  Unless there's a reason to do otherwise I
> >>> would expect that to be true of oslo.db too.
> >>
> >> Has that decision been re-evaluated recently?
> >>
> >> I feel like bug trackers are more useful when they are more focused. But
> >> perhaps there are other reasons behind using a shared bug tracker.
> > 
> > +1
> > 
> > The alternative (relying on users to tag bugs consistently) is error-prone.
> 
> The reason is that it's actually difficult to get a view of all "oslo"
> bugs due to Launchpad shortcomings (a project can only be in one project
> group). So keeping them in a single "project" simplifies the work of
> people that look after all of "Oslo".
> 
> This should be fixed in the future with a task tracker that handles
> project groups sanely, and then there is no reason at all to use the
> same project for different repositories.
> 

I know this sounds like a crazy idea, but have we looked at investing any
time in adding this feature to Launchpad?

TripleO has the same problem. We look at bugs for:

tripleo
diskimage-builder
os-apply-config
os-collect-config
os-refresh-config

Now, having all of those in one project is simply not an option, as they
are emphatically different things. Part of TripleO is allowing users to
swap pieces out for others, so having clear lines between components is
critical.

I remember similar problems working on juju, juju-jitsu, charm-tools,
and juju-core.

Seems like it would be worth a small investment in Launchpad vs. having
to switch to another tracker.



More information about the OpenStack-dev mailing list