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. 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. > > 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). -- Thierry Carrez (ttx) __________________________________________________________________________ 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
