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 ?
[1] https://blueprints.launchpad.net/openstack
[2] https://bugs.launchpad.net/openstack
--
Thierry Carrez (ttx)
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
