On Jul 28, 2016:4:30 PM, at 4:30 PM, Colin Dixon <colin@...> wrote:

During the TSC meeting, some of you asked why we didn't have a 6 month cadence and if we could get to one. I did my best to answer that on another thread here:
https://lists.opendaylight.org/pipermail/tsc/2016-July/005665.html

Generally, given that we're talking about rearranging *everything* in releases after Carbon, my take is that trying to align ourselves to 6 months now is probably more pain that it's worth. That being said, I'm open to other views if it really helps things.

--Colin

On Thu, Jul 28, 2016 at 12:47 PM, Colin Dixon <colin@...> wrote:

Also, no, I just missed skipped #2 by accident.

--Colin

On Thu, Jul 28, 2016 at 12:46 PM, Colin Dixon <colin@...> wrote:

I think that doing #1 internally while still externally following the traditional M0-M5, six-month release is not only doable, but will be essential if we want to actually get to the end of Carbon with some idea of if any of this works or not.

--Colin

On Thu, Jul 28, 2016 at 12:31 PM, Abhijit Kumbhare <abhijitkoss@...> wrote:

Fair point on #3. Was there a #2?

About #1 - an internal cycle by the individual downstream projects will likely not happen if its not a coordinated experiment with the participation by all the projects - as the projects will still need to proceed/develop as per the traditional Carbon schedule. Since that is likely to be the case - it might be better to have the Carbon release as per the traditional schedule.

On Thu, Jul 28, 2016 at 6:44 AM, Colin Dixon <colin@...> wrote:

A few quick notes:

1.) I think most of the hard/interest parts of a fast/phased release come in not just int he first 2-month cycle, but as that 2-month cycle cascades downstream into the next cycle and so on. A way to split the difference would be to have (some of) the offset 0 projects try a faster release cadence and/or semantic versioning with downstream projects relying on version range instead of a fixed SNAPSHOT version. They could have 2-month internal cycles as long as the APIs others were relying on were frozen and code-frozen in line with the 6-month release.

3.) I think we agreed that the TSC terms would end at the end of the Boron cycle, so it would take another vote (of the board) to change that.

Cheers,

--Colin

On Thu, Jul 28, 2016 at 1:56 AM, Abhijit Kumbhare <abhijitkoss@...> wrote:

One possibility that I had mentioned in the TSC meeting:

A small two-month bubble trial release (Oct-Nov) to explore the feasibility of a fast paced/staged release. If it works - we have a new fast paced staged release paradigm. If it does not work then the only bad side effect is that the release cycle got shifted by 2 months - and we will also have learned something. Based on the learning/experience we can then arrive at a decision that we will stick to the regular 6 month cycles for the foreseeable future (next few releases).  

Otherwise we will likely be at the same spot regarding the fast paced / staged release idea as we were at the beginning of Boron - i.e. the fast paced/staged idea being pushed to the next release.

The side-effect advantage of this will be that the TSC terms of the CAL members will be nearly restored to be on the calendar year boundaries with a November election to start the term of the new TSC just after this trial 2 month release. This also gets the time to get the mechanics of the new TSC membership sorted out in the DDF at the ODL Summit - as well as time for getting more projects to become mature, etc.

On Wed, Jul 27, 2016 at 11:14 AM, Daniel Farrell <dfarrell@...> wrote:

Colin's consensus summery sounds good to me.

+1 to Boron-like plan for Carbon. I think it's too late to build
understanding and momentum around something drastically different,
especially among less-active projects.

I'd love to see us use the ODL Dev Design Forum at Summit to put
a concrete pilot/test/plan in place, to run during Carbon and serve
as training/testing for adoption in Nitrogen.

Can we #action someone deeply involved to propose a DDF talk?

https://wiki.opendaylight.org/view/Events:Carbon_Dev_Forum#Topics

Thanks all,

Daniel Farrell
Software Engineer, Red Hat SDN Team
https://wiki.opendaylight.org/view/user:dfarrell07

----- Original Message -----
> I just wanted to bump this for any feedback before the TSC meeting on
> Thursday.
>
> --Colin
>
>
> On Thu, Jul 21, 2016 at 12:35 PM, Colin Dixon <colin@...> wrote:
>
> > During the debate leading to the approval of the Boron release plan, we
> > agreed that we would try have a concrete release plan ready by M2 to start
> > discussion [0]. However, despite repeated attempts [1,2,3] to spark a
> > discussion, it has been muted.
> >
> > During last week's TSC call [4], the consensus on the call was that
> > realistically, we did not have the time or cycles to invest in the tooling
> > required to do a Carbon release in a fast and/or phased way and have it
> > start anytime soon after Boron.
> >
> > Instead, the consensus seemed to be moving toward having a normal,
> > 5-milestone, 6-month Carbon release, but with more concrete details about
> > how we might actually make progress with tools and experience to enable
> > future releases to realistically consider different approaches. People
> > stated they'd really like to see those baked into release plans (both for
> > the whole simultaneous release and projects) so that they don't fall by the
> > wayside.
> >
> > On the other side, we have the need to provide some clarity to
> > projects—especially new projects as well as offset 1 and 2 projects, which
> > tend to follow discussions like this less closely—about what to expect from
> > a Carbon release.
> >
> > Along those lines, we agreed to set down "basic outline of the main Carbon
> > release, e.g., approx length and milestones w/approx dates" by 7/28.
> >
> > There's a draft version of a Carbon Release Plan that's just a the Boron
> > Release Plan with updated dates here:
> > https://wiki.opendaylight.org/view/Simultaneous_Release:Carbon_Release_Plan
> >
> > The basic sketch of dates is:
> >         offset 0        offset 1        offset 2
> > M0      9/22/2016 (2 weeks after Boron Release)
> > proj
> > prop du 10/6/2016       10/13/2016      10/20/2016
> > M1      10/20/2016      10/27/2016      11/3/2016
> > M2      11/17/2016      12/1/2016       12/8/2016
> >            shift dates after 11/24 by 1 week b/c Thanksgiving
> > M3      12/22/2016      1/19/2017       2/2/2017
> >            shift dates after 12/25 by 2 more weeks b/c
> >            Christmas and New Years
> > M4      2/2/2017        2/16/2017       3/2/2017
> > M5      3/2/2017        3/16/2017       3/30/2017
> > RC0     4/13/2017
> > RC1     4/20/2017
> > RC2     4/27/2017
> > RC3     5/4/2017
> > Release 5/11/2017 (8 months after Boron)
> > SR1     6/22/2017
> > SR2     8/10/2017 (shifted by 1 more week because of July 4th)
> > SR3     11/2/2017
> > SR4     2/15/2018 (shifted by 3 more weeks b/c of Thanksgiving,
> >                    Christmas and New Years)
> >
> > Cheers,
> > --Colin
> >
> > [0]
> > https://meetings.opendaylight.org/opendaylight-meeting/2016/tsc/opendaylight-meeting-tsc.2016-03-03-18.00.html
> > bullet 10.aq
> > [1] https://lists.opendaylight.org/pipermail/tsc/2016-May/005206.html
> > [2] https://lists.opendaylight.org/pipermail/tsc/2016-June/005428.html
> > [3] https://lists.opendaylight.org/pipermail/tsc/2016-July/005536.html
> > [4]
> > https://meetings.opendaylight.org/opendaylight-meeting/2016/tsc/opendaylight-meeting-tsc.2016-07-14-17.00.html
> > bullet 9
> >
>

> _______________________________________________
> TSC mailing list
> TSC@...
> https://lists.opendaylight.org/mailman/listinfo/tsc
>

_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc