Open Stack

On Thu, Aug 10, 2017 at 07:22:56PM +0900, Akihiro Motoki wrote:
> Tony,
> 
> Thanks for taking care.
> 
> > The following repos don't seem to use the openstack/releases repo so I
> > have less information there.
> 
> Most of them are projects not under the governance (so-called "hosted"
> or "unofficial" projects),
> so I am not sure there is a good way to handle them.
> 
> I can comment some of them which I am involved in deeply.
> 
> > i18n                                               I18n
> 
> At now, i18n repo is a part of governance but this is a project which
> has no need to cut a release,
> so it always follows the master branch of the requirements repo.
> It is not a blocker for opening the master branch in the requirements repo.

Okay I'll added that to the 'branchless' group.
 
> > neutron-vpnaas
> > neutron-vpnaas-dashboard
> 
> These projects are neutron related and horizon plugin.
> We will do same things for other neutron stadium and horizon plugin projects.
> 
> IMHO we don't need to take care of them much.

As long as you block bot-updates from the time we branch (pike) until the time
you branch (pike) that is all that needs to happen
 
> > python-openstacksdk
> 
> python-openstackclient depends on this, so we need to cut stable/branch
> from the latest release. The status of the project is being discussed
> in the ML thread,
> but I believe we need to cut a stable branch. On the other hand, I
> think it does not
> block the opening of the master of the requirements repo as the latest
> release of
> python-openstacksdk is enough for Pike release of OSC.

As with the neutron-vpnaas repos, you need to block to bit updates or it
*does* block (or hamper) the requirements repo from re-opening master.

> > It'd be great to get some of these repos represented in
> > openstack/releases.  Having a confirmed release-model would go a long
> > way to clearing up the list. An alternate approach would be to remove
> > redundant items from projects.txt
> 
> I am not sure that projects not under the TC governance can use
> openstack/releases repo.
> Is the openstack/release repo for projects under the governance?

I didn't think that was the rule but it's certainly been said enough in
the last 24 hours that it probably is correct.

With that in mind we'd do better if there was a process for Openstack
Hosted projects to follow.

Perhaps they could maintain a 'deliverables/<series>/<project>.yaml in
their own repo that would mirror (but probably get out od sync with,
openstack/releases.  From a requirements POV I just need somewheer to
look for data on the projects that are managed but not official.

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170811/c88cc207/attachment.sig>