OPNFV releases in late September and late March. The naive answer is that
it gives them 2-3 weeks to integrate. The less naive answer is that they
have 4-7 weeks to integrate using our RCs. While our RCs aren't always
stable, the parts that OPNFV integrates with are usually the more stable
parts of our RCs and integration does happen in practice during that period.

The same general principle applies to our integration with OpenStack.

Further, there was actually pretty strong feeling that this would do a
better job of aligning mindsets between the different projects since we
will likely be thinking about release and integration at the same time
instead of one project thinking about release and integration while the
other is still finishing up features.

--Colin


On Thu, Apr 13, 2017 at 9:44 AM, Ed Warnicke <[email protected]> wrote:

> How does this line up with OpNFV?
>
> Ed
>
> On Thu, Apr 13, 2017 at 9:40 AM, Colin Dixon <[email protected]> wrote:
>
>> Based on feedback from talking with OPNFV and OpenStack people at ONS,
>> we've heard from a large number of people that the general idea of
>> releasing at roughly the same time as OpenStack would be useful. We've also
>> found out that the shift in release dates for OpenStack was a one-time
>> adjustment as they factor their DDFs out of their summits.
>>
>> That means that OpenStack will be targeting late February and late March
>> releases going forward. That being combined with the existing preference
>> from a lot of people that early March and early September were good dates
>> for OpenDaylight releases means our current plan is to have a small
>> Nitrogen releases to line up with 3/7 and 9/7 releases going forward. So,
>> something like this.
>>
>> Nitrogen Mini-release Schedule
>> ----
>>
>>          off0  off1   off2
>>   start: 5/7
>> ??   M1: 5/21  5/28   6/7    [Release Plan] (we could do this if we
>> wanted to, but overhead)
>>      M3: 6/21  6/28   7/7    [API freeze]
>>      M4: 7/21  7/28   8/7    [Code freeze]
>>     RCs: 8/7-9/7 (continuous build)
>> release: 9/7
>>     SR1: 10/7
>>     SR2: 12/7
>>     SR3: 2/7
>>     SR4: somewhere in 3/21-5/7
>>
>> Oxygen (and all future even element number releases)
>> ----
>>
>>          off0  off1   off2
>>   start: 9/7
>>      M1: 10/7  10/14  10/21
>>      M2: 11/7  11/14  11/21
>>      M3: 12/7  12/14  12/21  [note M3-M4 will likely be short since
>>      M4: 1/7   1/14   1/21    it includes 12/25-1/1]
>>     RCs: 1/21-3/7 (continuous build)
>> release: 3/7
>>     SR1: 4/7
>>     SR2: 6/7
>>     SR3: 8/7
>>     SR4: somewhere in 9/21-11/7
>>
>>
>> Fluorine (and all future odd element number releases)
>> ----
>>
>>          off0  off1   off2
>>   start: 3/7
>>      M1: 4/7   4/14   4/21
>>      M2: 5/7   5/14   5/21
>>      M3: 6/7   6/14   6/21
>>      M4: 7/7   7/14   7/21
>>     RCs: 7/21-9/7 (continuous build)
>> release: 9/7
>>     SR1: 10/7
>>     SR2: 12/7
>>     SR3: 2/7
>>     SR4: somewhere in 3/21-5/7
>>
>> Note that this makes the assumptions that:
>> 1.) We will combine M1 and M2 and require a final release plan at that
>> time.
>> 2.) All other milestones shift down by one, so M2 is feature freeze, M3
>> is API freeze and M4 is code freeze
>> 3.) We would have SRs 1, 3, and 5 months after the release and the final
>> SR would fall sometime in between 2 weeks and 2 months after the next
>> release
>>
>> None of this is final, but it is the grown consensus of the working group
>> and we're looking to get feedback.
>>
>> --Colin
>>
>>
>> _______________________________________________
>> TSC mailing list
>> [email protected]
>> https://lists.opendaylight.org/mailman/listinfo/tsc
>>
>>
>
_______________________________________________
Discuss mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/discuss

Reply via email to