Akihiro Motoki <[email protected]> wrote:
2016-07-29 18:34 GMT+09:00 Ihar Hrachyshka <[email protected]>:
Cathy Zhang <[email protected]> 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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
