On Fri, Jul 17, 2015 at 3:02 AM, Thierry Carrez <[email protected]> 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 <[email protected]> > >> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Anne Gentle Rackspace Principal Engineer www.justwriteclick.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
