On 08/22/2014 11:59 AM, Thierry Carrez wrote:
> TL;DR:
> Let's create an Oslo projectgroup in Launchpad to track work across all
> Oslo libraries. In library projects, let's use milestones connected to
> published versions rather than the common milestones.
>
> Long version:
> As we graduate more Oslo libraries (which is awesome), tracking Oslo
> work in Launchpad (bugs, milestones...) has become more difficult.
>
> There used to be only one Launchpad project ("oslo", which covered the
> oslo incubator). It would loosely follow the integrated milestones
> (juno-1, juno-2...), get blueprints and bugs targeted to those, get tags
> pushed around those development milestones: same as the integrated
> projects, just with no source code tarball uploads.
>
> When oslo.messaging graduated, a specific Launchpad project was created
> to track work around it. It still had integrated development milestones
> -- only at the end it would publish a 1.4.0 release instead of a 2014.2
> one. That approach creates two problems. First, it's difficult to keep
> track of "oslo" work since it now spans two projects. Second, the
> release management logic of marking bugs "Fix released" at development
> milestones doesn't really apply (bugs should rather be marked released
> when a published version of the lib carries the fix). Git tags and
> Launchpad milestones no longer align, which creates a lot of confusion.
>
> Then as more libraries appeared, some of them piggybacked on the general
> "oslo" Launchpad project (generally adding tags to point to the specific
> library), and some others created their own project. More confusion ensues.
>
> Here is a proposal that we could use to solve that, until StoryBoard
> gets proper milestone support and Oslo is just migrated to it:
>
> 1. Ask for an "oslo" project group in Launchpad
>
> This would solve the first issue, by allowing to see all oslo work on
> single pages (see examples at [1] or [2]). The trade-off here is that
> Launchpad projects can't be part of multiple project groups (and project
> groups can't belong to project groups). That means that Oslo projects
> will no longer be in the "openstack" Launchpad projectgroup. I think the
> benefits outweigh the drawbacks here: the openstack projectgroup is not
> very strict anyway so I don't think it's used in people workflows that much.
>
> 2. Create one project per library, adopt tag-based milestones
>
> Each graduated library should get its own project (part of the oslo
> projectgroup). It should use the same series/cycles as everyone else
> ("juno"), but it should have milestones that match the alpha release
> tags, so that you can target work to it and mark them "fix released"
> when that means the fix is released. That would solve the issue of
> misaligned tags/milestones. The trade-off here is that you lose the
> common milestone rhythm (although I guess you can still align some
> alphas to the common development milestones). That sounds a small price
> to pay to better communicate which version has which fix.
>
> 3. Rename "oslo" project to "oslo-incubator"
>
> Keep the Launchpad "oslo" project as-is, part of the same projectgroup,
> to cover oslo-incubator work. This can keep the common development
> milestones, since the incubator doesn't do "releases" anyway. However,
> it has to be renamed to "oslo-incubator" so that it doesn't conflict
> with the projectgroup namespace. Once it no longer contains graduated
> libs, that name makes much more sense anyway.
>
>
> This plan requires Launchpad admin assistance to create a projectgroup
> and rename a project, so I'd like to get approval on it before moving to
> ask them for help.
>
> Comments, thoughts ?
I like this proposal! +1 from me!
>
> [1] https://blueprints.launchpad.net/openstack
> [2] https://bugs.launchpad.net/openstack
>
--
@flaper87
Flavio Percoco
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
