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