Open Stack

On Thu, Nov 29, 2018 at 05:22:48PM +0100, Thierry Carrez wrote:
> Hi, QA folks,
> 
> The release management team has been conducting a review of OpenStack
> official deliverables, to make sure nothing was falling between the cracks
> release-management-wise.
> 
> As part of that review, we added a "release-management:" key to deliverables
> defined in the project governance repository in case they were not to be
> handled by the release management team using the openstack/releases
> repository. For example, some deliverables (like docs) are continuously
> published and therefore marked "release-management:none". Others (like
> charms) are released manually on 3rd-party platforms and therefore marked
> "release-management:external".
> 
> In that context, several QA-maintained tools or related repos are a bit in
> limbo:
> 
> * eslint-config-openstack: used to be released regularly, but was never
> released since we introduced openstack/releases. Should we just consider it
> cycle-independent, or drop the repository from governance ?

This is a cycle independent tool, it's the equivalent of hacking but for js
code. I know that projects are still using it, even if it's not super active
the rules are pretty static and haven't need an update in a while.

> 
> * devstack-vagrant: never released, no change over the past year. Is it
> meant to be released in the future (cycle-independent) or considered
> continuously published (release-management:none) or should it be retired ?

I'll wait for gmann to weigh in on retiring it or not, but it doesn't need
releases, it's just a tool repo for deploying a VM and setting up devstack
using vagrant. It hasn't been active in a couple years, personally I've never
used it so I don't know if it even works still or not. I'd vote for retiring
it, but I haven't paid attention to it in a long time, so maybe it's still
useful.

> 
> * karma-subunit-reporter: saw some early releases two years ago but not in
> recent times.  Should we just consider it cycle-independent, or drop the
> repository from governance ?

This is also cycle independent, it's a tool for generating subunit streams
from karma test runs. It's something we use for js unit tests and getting
results into openstack-health and similar tools. It's also used externally
a couple places.

> 
> * devstack-plugin-*: Some of those were branched using openstack/releases
> back in Queens, but only devstack-plugin-container. was branched in Rocky.
> Some consistency here would be good. Should those all be branched every
> cycle in the future, or should we just branch none of them and consider them
> all continuously published (release-management:none) ?

These would only ever be branched, since like devstack there aren't actually
releases for it, just branches. As for the status of the plugins different ones
are maintained by different teams depending on the plugins. I know a few fall
under QA, but I personally don't know the status of them or whether they still
work or not.

> 
> * devstack-tools: saw some early releases two years ago but not in recent
> times.  Should we just consider it cycle-independent, or consider it
> abandoned ?

This is a package that is also cycle-independent, it's a support tool for
devstack which is still used there. It just performs some operations which
were much easier to write in python then in bash (mainly around manipulating
config files iirc). Its usage is pretty stable right now so we haven't
needed to release it in a while.

-Matt Treinish
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20181129/3e376e05/attachment.sig>