[dev][qa][devstack] Release management for QA toold and plugins

Ghanshyam Mann gmann at ghanshyammann.com
Fri Nov 30 02:39:16 UTC 2018


 ---- On Fri, 30 Nov 2018 04:16:36 +0900 Matthew Treinish <mtreinish at kortar.org> wrote ---- 
 > 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. 

Yeah, This and other few QA tools are kind of not required much development and static but they
are being used. As matt mentioned, they are cycle independent tool and get a release on the need basis.
As they do not require much resource bandwidth and might be used by someone, there is no harm to
keeping them in QA. I am not sure which release tag we should give to them
("release-management:none" and "release-management:external" does not fit for them) but I am ok to keep
their release model as it is and give some appropriate tag.

 >  
 > >  
 > > * 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. 

I am ok to retire this based on no one using it. And honestly saying, it is hard to judge that
no one using it especially from the users who are not engaged in community communication etc.
But i can start the ML and summit/PTG discussion to check its usage and then take the decision.  

 >  
 > >  
 > > * 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. 

ditto as eslint-config-openstack.

 >  
 > >  
 > > * 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. 

I am not aware of all plugins but plugins  under QA are:
- devstack-plugin-container - as you mentioned, it is branched.
- devstack-plugin-ceph - This is branchless. 

About branching them consistently, I will say it depends on plugin scope whether that needs to be branched or not.
For example, devstack-plugin-ceph was not required as branched as no branch specific things in that. ceph configuration
is all same for all branch.  Doing branch on this will be unnecessary work. 

 >  
 > >  
 > > * 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. 

Ditto as eslint-config-openstack


-gmann

 >  
 > -Matt Treinish 
 > 





More information about the openstack-discuss mailing list