Open Stack

Doug Hellmann wrote:
> 
> On Aug 22, 2014, at 5:59 AM, Thierry Carrez <thierry at openstack.org> 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.
> 
> We don’t necessarily decide the version numbers for all of the libraries in advance. I think we talked about this on IRC, and your suggestion was to use a “next” milestone and then rename it at the point of release. Am I remembering correctly?

Yes, using "next" and renaming it once you know is the way to go.

>> 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
>>
> 
> This makes sense to me, so let’s move ahead with your plan.

I'd like to wait for Mark McLoughlin's position, as he was defending the
current setup (oslo.messaging following the juno-X milestones).

> It would be good if we had a script to automate some of the release processes now, and it seems like this change is going to make it easier to implement parts like marking all of the tickets as released and updating their milestone.

I'll come up with tooling to facilitate releasing of Oslo libs.

> We do have launchpad projects for some of the other oslo libraries, we just haven’t been using them for release tracking:
> 
> https://launchpad.net/python-stevedore
> https://launchpad.net/python-cliff
> https://launchpad.net/taskflow
> https://launchpad.net/pbr
> https://launchpad.net/oslo.vmware

Cool, good to know. I'll include them in the oslo group if we create it.

-- 
Thierry Carrez (ttx)