I count 5 TSC members on this thread in favor of the twice a year release
cadence. I also think that OPNFV targets twice a year and OpenECOMP is like
to do the same. Are there people that are willing to sit down and look over
the work we've done in the past at this and providing a recommendation on
what choices we should make to go from ~8 month releases to 24-week
releases?

I think there's a lot of good starting material to work with, but it would
be good if some subset of the TSC could do some work offline and make a
cogent recommendation.

--Colin


On Thu, Feb 9, 2017 at 8:35 PM, Luis Gomez <[email protected]> wrote:

> +1, twice a year.
>
> On Feb 9, 2017, at 4:58 PM, Thanh Ha <[email protected]> wrote:
>
> I think moving to a twice a year schedule is a good idea.
>
> Thanh
>
> On Thu, Feb 9, 2017 at 3:19 PM, Abhijit Kumbhare <[email protected]>
> wrote:
>
>> Alignment the release schedules with OpenStack & other communities makes
>> sense.
>>
>> On Thu, Feb 9, 2017 at 12:03 PM, Ryan Goulding <[email protected]>
>> wrote:
>>
>>> +1
>>>
>>> Regards,
>>>
>>> Ryan Goulding
>>>
>>> On Thu, Feb 9, 2017 at 2:28 PM, Andre Fredette <[email protected]>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Feb 9, 2017 at 1:45 PM, Colin Dixon <[email protected]>
>>>> wrote:
>>>>
>>>>> From today's TSC call, it sounds like 1.) is more technical and
>>>>> probably either wants an ongoing call or mailing list thread of it's own 
>>>>> to
>>>>> go over the technical needs and how we might take a whack at it.
>>>>>
>>>>> --Colin
>>>>>
>>>>>
>>>>> On Thu, Feb 9, 2017 at 11:36 AM, Colin Dixon <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> I know it feels way too early, but it's actually getting to be
>>>>>> relatively late to talk about planning the Nitrogen release. I know the
>>>>>> last few releases, we've talked about making pretty substantial changes 
>>>>>> and
>>>>>> just ran out of steam to implement them.
>>>>>>
>>>>>> This time, I'm going to propose something slightly different. Why
>>>>>> don't we try one or two more minor changes. The two relatively simple
>>>>>> changes that come to my mind first are:
>>>>>>
>>>>>> 1.) Moving to having a common version range for each artifact rather
>>>>>> than a common version. That is moving from x.y.z-SNAPSHOT to x.y.[z,z+1) 
>>>>>> or
>>>>>> maybe even x.[y,y+1) and then have merge jobs publish both SNAPSHOT as 
>>>>>> well
>>>>>> as release artifacts with a build number as fourth part of the version. 
>>>>>> I'm
>>>>>> sure that there are details I'm glossing over (and I know of a few), but 
>>>>>> it
>>>>>> would be a relatively simple step toward decoupling some of our release
>>>>>> process. Some information on this is in an old thread here too:
>>>>>> https://lists.opendaylight.org/pipermail/tsc/2016-July/005536.html
>>>>>>
>>>>>> 2.) Moving to a twice a year release process. This would help
>>>>>> planning by not having our release dates shift randomly around each year,
>>>>>> fall more in line with other open source projects, get us cycling a bit
>>>>>> faster, and maybe also have some more discipline. I talked about it a bit
>>>>>> before here:
>>>>>> https://lists.opendaylight.org/pipermail/tsc/2016-July/005665.html
>>>>>>
>>>>>
>>>> As many probably know, OVS is moving to a twice a year release schedule
>>>> and is aligning with OpenStack:
>>>> https://mail.openvswitch.org/pipermail/ovs-dev/2016-November
>>>> /324752.html
>>>>
>>>> Many of our projects depend on OVS and also work with OpenStack.  It
>>>> seems that a similar alignment would be beneficial for ODL.
>>>>
>>>> Andre
>>>>
>>>
> _______________________________________________
> TSC mailing list
> [email protected]
> https://lists.opendaylight.org/mailman/listinfo/tsc
>
>
>
> _______________________________________________
> 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