Open Stack

On 07/17/2015 10:02 AM, Thierry Carrez wrote:
> Doug Hellmann wrote:
>> Excerpts from Anne Gentle's message of 2015-07-16 08:14:54 -0500:
>>> On Thu, Jul 16, 2015 at 6:58 AM, Doug Hellmann <doug at doughellmann.com>
>>> wrote:
>>>
>>>> Excerpts from Andreas Jaeger's message of 2015-07-16 08:11:48 +0200:
>>>>> Doug,
>>>>>
>>>>> I'm missing openstackdocstheme and openstack-doc-tools in your import.
>>>>> How do you want to handle these?
>>>>
>> One sticking point with these tools is that they don't fit into our
>> current definition of a deliverable, which is "N repos that share a
>> launchpad project and version number."
>
> My non-technical definition for a deliverable (or "a thing we release")
> is a produce of the project team that is intended to be used by others,
> and therefore new releases need to be published and communicated.
>
> Since it is meant to be used by others, those should also have a
> Launchpad project so that users can report issues with it.
>
> So the question here is more: are openstackdocstheme and
> openstack-doc-tools products of the Documentation project team that are
> intended to be used outside of that team.
>
> If the answer is "yes" then they should have a Launchpad project and be
> considered a deliverable. If the answer is "no" then while they may have
> tags, they don't really need releases or direct user feedback, so the
> Launchpad project may be overkill.
>
> openstack-doc-tools seems to lean in the "yes" direction, I could find
> it used by a couple projects in test-requirements.

It's used by openstack-manuals and similar doc repos and trove for 
building and checking of DocBook XML files.

>
> openstackdocstheme seems to be used only in infra, so I guess it could
> go either way. I'm not really sure what releases/tags achieve there...

It's used by all doc projects using RST files for documentation: 
openstack-manuals, security-doc etc.

Releases are needed for both since we do build from a released version, 
and they are used by projects outside of the Documentation team like 
trove or security-doc.

We currently handle bugs for these as part of openstack-manuals.

>> 1. Create separate launchpad projects for each of them, so they can be
>> managed independently like the other projects.
>>
>> 2. Start releasing and versioning them together.
>>
>> 3. Add support for a deliverable type with no launchpad project, which
>> would skip the launchpad updates.
>>
>> I like option 1, with 3 being a fallback. I don't really see option 2 as
>> viable.
>>
>> What does everyone else think?
>
> Following my train of thoughts from the "deliverable" definition above,
> option 1 is the only that makes sense (with option 2 as a backup, but
> that would not be a good fit in this particular case).

I agree, we treat them as deliverables, so let me setup launchpad 
projects for these...

Andreas
-- 
  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
    GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
        HRB 21284 (AG Nürnberg)
     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126