Re: [openstack-dev] [release] Re: [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed
On Tue, Nov 29, 2016 at 11:53 AM, Takashi Yamamoto wrote: > release team, > > can we (networking-midonet) branch stable/newton from a past commit > with a RC tag, backport some changes [1], and then cut the first release > on the branch? to answer myself, RC or beta-looking tag doesn't seem to be allowed for release:independent projects. [1] so i went ahead with 3.0.0. [2] [1] https://github.com/openstack/releases/blob/745554fdec87b18fe0a39fa25cdc481b23f28d24/openstack_releases/versionutils.py#L48-L49 [2] https://review.openstack.org/#/c/404078/ > > [1] some addititonal features without db migrations (qos, lbaasv2, ...) and > removal of some unsupported code (lbaasv1, ...) > > On Fri, Nov 25, 2016 at 11:32 PM, Ihar Hrachyshka wrote: >> >>> On 25 Nov 2016, at 15:23, Takashi Yamamoto wrote: >>> >>> On Fri, Nov 25, 2016 at 8:02 PM, Ihar Hrachyshka >>> wrote: > On 25 Nov 2016, at 11:02, Takashi Yamamoto wrote: > > On Fri, Nov 25, 2016 at 6:54 PM, Ihar Hrachyshka > wrote: >> >>> On 25 Nov 2016, at 09:25, Takashi Yamamoto >>> wrote: >>> >>> On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka >>> wrote: > On 25 Nov 2016, at 05:26, Takashi Yamamoto > wrote: > > hi, > > networking-midonet doesn't have stable/newton branch yet. > newton jobs failures are false alarms. > > branching has been delayed because development of some futures > planned for newton has not been completed yet. > > the plan is to revert ocata-specific changes after branching newton. I don’t think it’s a good idea since you will need to tag a release on branch creation, that is supposed to be compatible with next releases in that same branch. >>> >>> can't we create the tag after the revert? >>> >> >> No, that’s release team requirement that they branch on a release tag. > > ok, i didn't know the requirement. thank you. > >> >>> anyway no one think this is a good idea. >>> it's just an unfortunate compromise we ended up. >>> we are trying to make the schedule better for next release. >> >> It would make more sense to tag on a compatible commit from the past and >> consider it a first stable release. (Of course it means that feature >> development would need to be aligned appropriately.) > > in that case, can we backport the features? > (namely qos and lbaas drivers are in my mind) No, I don’t think so. Though maybe we can release an RC as the first tag in the branch and backport features before releasing a final version? I dunno, I guess you will need to talk to OpenStack release folks on how to proceed. >>> >>> is it a release team matter? >>> i thought these were a policy inside neutron. >>> after all networking-midonet is release:independent. >> >> Neutron does not override global policies. I explicitly asked during the >> last summit if we can branch before a tag; the answer was no, it’s not an >> option. >> >> Adding [release] tag since it becomes a matter beyond neutron. >> >> Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [release] Re: [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed
release team, can we (networking-midonet) branch stable/newton from a past commit with a RC tag, backport some changes [1], and then cut the first release on the branch? [1] some addititonal features without db migrations (qos, lbaasv2, ...) and removal of some unsupported code (lbaasv1, ...) On Fri, Nov 25, 2016 at 11:32 PM, Ihar Hrachyshka wrote: > >> On 25 Nov 2016, at 15:23, Takashi Yamamoto wrote: >> >> On Fri, Nov 25, 2016 at 8:02 PM, Ihar Hrachyshka wrote: >>> On 25 Nov 2016, at 11:02, Takashi Yamamoto wrote: On Fri, Nov 25, 2016 at 6:54 PM, Ihar Hrachyshka wrote: > >> On 25 Nov 2016, at 09:25, Takashi Yamamoto wrote: >> >> On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka >> wrote: >>> On 25 Nov 2016, at 05:26, Takashi Yamamoto wrote: hi, networking-midonet doesn't have stable/newton branch yet. newton jobs failures are false alarms. branching has been delayed because development of some futures planned for newton has not been completed yet. the plan is to revert ocata-specific changes after branching newton. >>> >>> I don’t think it’s a good idea since you will need to tag a release on >>> branch creation, that is supposed to be compatible with next releases >>> in that same branch. >> >> can't we create the tag after the revert? >> > > No, that’s release team requirement that they branch on a release tag. ok, i didn't know the requirement. thank you. > >> anyway no one think this is a good idea. >> it's just an unfortunate compromise we ended up. >> we are trying to make the schedule better for next release. > > It would make more sense to tag on a compatible commit from the past and > consider it a first stable release. (Of course it means that feature > development would need to be aligned appropriately.) in that case, can we backport the features? (namely qos and lbaas drivers are in my mind) >>> >>> No, I don’t think so. Though maybe we can release an RC as the first tag in >>> the branch and backport features before releasing a final version? I dunno, >>> I guess you will need to talk to OpenStack release folks on how to proceed. >> >> is it a release team matter? >> i thought these were a policy inside neutron. >> after all networking-midonet is release:independent. > > Neutron does not override global policies. I explicitly asked during the last > summit if we can branch before a tag; the answer was no, it’s not an option. > > Adding [release] tag since it becomes a matter beyond neutron. > > Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [release] Re: [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed
> On 25 Nov 2016, at 15:23, Takashi Yamamoto wrote: > > On Fri, Nov 25, 2016 at 8:02 PM, Ihar Hrachyshka wrote: >> >>> On 25 Nov 2016, at 11:02, Takashi Yamamoto wrote: >>> >>> On Fri, Nov 25, 2016 at 6:54 PM, Ihar Hrachyshka >>> wrote: > On 25 Nov 2016, at 09:25, Takashi Yamamoto wrote: > > On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka > wrote: >> >>> On 25 Nov 2016, at 05:26, Takashi Yamamoto >>> wrote: >>> >>> hi, >>> >>> networking-midonet doesn't have stable/newton branch yet. >>> newton jobs failures are false alarms. >>> >>> branching has been delayed because development of some futures >>> planned for newton has not been completed yet. >>> >>> the plan is to revert ocata-specific changes after branching newton. >> >> I don’t think it’s a good idea since you will need to tag a release on >> branch creation, that is supposed to be compatible with next releases in >> that same branch. > > can't we create the tag after the revert? > No, that’s release team requirement that they branch on a release tag. >>> >>> ok, i didn't know the requirement. thank you. >>> > anyway no one think this is a good idea. > it's just an unfortunate compromise we ended up. > we are trying to make the schedule better for next release. It would make more sense to tag on a compatible commit from the past and consider it a first stable release. (Of course it means that feature development would need to be aligned appropriately.) >>> >>> in that case, can we backport the features? >>> (namely qos and lbaas drivers are in my mind) >> >> No, I don’t think so. Though maybe we can release an RC as the first tag in >> the branch and backport features before releasing a final version? I dunno, >> I guess you will need to talk to OpenStack release folks on how to proceed. > > is it a release team matter? > i thought these were a policy inside neutron. > after all networking-midonet is release:independent. Neutron does not override global policies. I explicitly asked during the last summit if we can branch before a tag; the answer was no, it’s not an option. Adding [release] tag since it becomes a matter beyond neutron. Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
