[openstack-dev] [all][ptl][release] New library release request process
annegentle at justwriteclick.com
Fri Jul 17 12:42:51 UTC 2015
On Fri, Jul 17, 2015 at 3:02 AM, Thierry Carrez <thierry at openstack.org>
> 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?
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev