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 <[email protected]> wrote: > >> On 25 Nov 2016, at 15:23, Takashi Yamamoto <[email protected]> wrote: >> >> On Fri, Nov 25, 2016 at 8:02 PM, Ihar Hrachyshka <[email protected]> wrote: >>> >>>> On 25 Nov 2016, at 11:02, Takashi Yamamoto <[email protected]> wrote: >>>> >>>> On Fri, Nov 25, 2016 at 6:54 PM, Ihar Hrachyshka <[email protected]> >>>> wrote: >>>>> >>>>>> On 25 Nov 2016, at 09:25, Takashi Yamamoto <[email protected]> wrote: >>>>>> >>>>>> On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>>> On 25 Nov 2016, at 05:26, Takashi Yamamoto <[email protected]> >>>>>>>> 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
