Open Stack

Akihiro Motoki <amotoki at gmail.com> wrote:

> 2016-07-29 18:34 GMT+09:00 Ihar Hrachyshka <ihrachys at redhat.com>:
>> Cathy Zhang <Cathy.H.Zhang at huawei.com> wrote:
>>
>>> Hi Ihar and all,
>>>
>>> Yes, we have been preparing for such a release. We will do one more round
>>> of testing to make sure everything works fine, and then I will submit the
>>> release request.
>>> There is a new patch on "stadium: adopt openstack/releases in subproject
>>> release process" which is not Merged yet.
>>> Shall I follow this
>>> http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html#sub-project-release-process
>>> to submit the request?
>>> Do you have a good bug example for Neutron sub-project release request?
>>
>>
>> For the time being, until the patch landds, you may follow any of those
>> directions.
>>
>> An example of a release request bug is:
>> https://bugs.launchpad.net/networking-bagpipe/+bug/1589502
>>
>>> BTW, a functional and tempest patch for networking-sfc has been uploaded
>>> and it might take some time for the team to complete the review. The  
>>> test is
>>> non-voting. Do you think we should wait until this patch is merged or
>>> release can be done without it?
>>
>>
>> It would be great to have CI voting, but then, you already lag with the
>> release for months comparing to release date of Neutron Mitaka, and you  
>> risk
>> getting into Phase II support mode before you even release the first
>> version. If you don’t envision release blocker bugs in the branch, I would
>> suggest you release the thing and then follow up with bug fixes for  
>> whatever
>> you catch later on. In a way, it’s better to release a half baked release
>> than to not release at all. That’s to follow the ‘release often’ mantra,  
>> and
>> boost adoption.
>
> I agree with Ihar, but I think there are several points to be checked
> before the release.
>
> - The code should be tested against mitaka version of neutron.
>   Currently the master branch of networking-sfc is tested against neutron master
>   and we haven't tested it against neutron stable/mitaka after Mitaka
> was released.

That’s why we suggest* in devref to release at around same time as neutron:

*  
http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html#stable-branches

"Stable branches for subprojects should be created at the same time when  
corresponding neutron stable branches are created. This is to avoid  
situations when a postponed cut-off results in a stable branch that  
contains some patches that belong to the next release. This would require  
reverting patches, and this is something you should avoid."

>
> - networking-sfc branch already contains newton db migration (see
> db/migration/alambic_migrations/versions/newton).
>   What I am not sure is whether it needs to be a part of mitaka release or not,
>   but you need to be careful when cutting stable/mitaka branch.

Good catch. From alembic perspective, it does not matter where scripts are  
located, so it’s probably minor.

Ihar