Open Stack

On Fri, Jul 17, 2015 at 3:02 AM, Thierry Carrez <thierry at openstack.org>
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.
>
> 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...
>
> > 1. Create separate launchpad projects for each of them, so they can be
> > managed independently like the other projects.
> >
>

Okay, we currently track both of these with the openstack-manuals project
in Launchpad but it's fine to create separate Launchpad projects for each.



> > 2. Start releasing and versioning them together.
>

No reason for this really that I can think of.


> >
> > 3. Add support for a deliverable type with no launchpad project, which
> > would skip the launchpad updates.
>

Would a single Launchpad project work for both, or not?

Thanks,
Anne


> >
> > 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).
>
> --
> Thierry Carrez (ttx)
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150717/0d888bb2/attachment.html>