Open Stack

On Fri, Nov 25, 2016 at 6:54 PM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
>
>> On 25 Nov 2016, at 09:25, Takashi Yamamoto <yamamoto at midokura.com> wrote:
>>
>> On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
>>>
>>>> On 25 Nov 2016, at 05:26, Takashi Yamamoto <yamamoto at midokura.com> 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)

>
> I see that subprojects do the same mistake over and over (the previous time it was sfc, but I’ve heard similar concerns from bgpvpn). I believe that we should set clear expectations for all stadium participants about when they first stable releases happen and when branches are created. The current lack of guidelines for participants just makes it harder for the core team to maintain the setting, and for subprojects to become good citizens.
>
> Ihar