On Nov 3, 2014, at 4:35 PM, Colin Dixon <colin@...> wrote:

So, in essence, this is just moving M1 out so that there are four weeks (plus an extra week to account for Thanksgiving) after this week for projects to meet the M1 dates. I have a more detailed scanning of the proposal with a few questions below, but I still want to push back on the need to do this.

The core reason I've heard for moving the M1 date out (so far only from Ed) has been to allow for the development of better per-project release plans. I think that moving M1 out is actually going to lead to WORSE, not better release plans for most projects.

In Helium, my observation was that most projects put together the most basic release plan they could just before the M1 milestone because that was all that was required. Unless we put extra requirements on the candidate release plans, and likely even if we do, I would expect this to happen again.

If we really want to improve the per-project release plans, I think we need to do something akin to the Karaf happy hour where we review and help projects improve their release plans, particularly in the area of cross-project needs. To do that, we really need projects to have at least a candidate release plan, which means it MUST happen after M1, so we should make M1 as soon as we feasibly can with the intent of using the time between M1 and M2 to actively improve release plans.

My proposal would be to leave the dates where they are and instead provide weekly release plan review sessions (similar to release review, but hopefully with more feedback) between M1 and M2. I'd like to avoid adding extra time, but IF we want to, it should be between M1 and M2.

--Colin

===

I'm just reiterating what you had with differences from the current draft (in weeks) here:

n/a    M0: 11/7/2014
+~3    Last Date for new Projects: Nov 27 (offset0)
+3    M1 12/12/2014 ( 1 extra week for Thanksgiving )
+2    M2: 1/23/2015 ( 2 extra weeks for Christmas)
+2    M3: 2/20/2015
+2    M4: 3/20/2015
+2    M5: 4/17/2015
+2    RC0: 5/29/2015
+2    RC1: 6/12/2015
+2    RC2: 6/26/2015
+1    Formal Release: 7/3/2015
+0    SR1: 8/14/2015
+0    SR2: 9/25/2015

Looking at things, you've adjusted M0 to have the new definition that it must come after the release plan is approved and then moved all the other dates forward two weeks except for:

1.) M1 and last date for new projects are by 3 weeks since they fall after thanksgiving, whereas before they do not

2.) The formal release is only moved forward by 1 week

3.) The stable updates are not moved

Was that the intent? It seems like we should move the stable updates back by just as much as the formal release. It's also not clear to me why we move the formal release plan out less than everything else.

On Mon, Nov 3, 2014 at 2:59 PM, Ed Warnicke (eaw) <eaw@...> wrote:

Colin,
        Per the discussion about leaving adequate time M0->M1 and M1->M2, I wanted to throw out some
concrete date proposals.

        I think you’ve expressed agreement that M0 should start from roughly when we
approve the SR Plan (which we are hoping to do this Thursday).  For sake of discussion, I wanted
to make a concrete date proposal (all dates for which offsets apply are offset 0 dates, with the 2 week
and 4 week add for offset 1 and offset 2 respectively:


M0 :11/7/2014
Last Date for new Projects: Nov 27 (offset0)
M1 12/12/2014 ( 1 extra week for Thanksgiving )
M2: 1/23/2015 ( 2 extra weeks for Christmas)
M3: 2/20/2015
M4: 3/20/2015
M5: 4/17/2015
RC0: 5/29/2015
RC1: 6/12/2015
RC2: 6/26/2015
Formal Release: 7/3/2015
SR1: 8/14/2015
SR2: 9/25/2015

Thoughts?

Ed

> On Nov 3, 2014, at 12:47 PM, Kent Watsen <kwatsen@...> wrote:
>
>
>
>>> Leadership & Communication
>>>
>>> OLD: The Project Lead will be subscribed to the release mailing list
>>> and must respond to requests send to the a timely fashion
>>> NEW: The Project Lead will be subscribed to the "release" mailing list
>>> and must respond to requests sent to it in a timely fashion
>>
>> I'm curious what the logic is here? Is it to make it italics or bold?
>
>
> It's a nit, admittedly, but I've always felt that references to lowercase
> names should be in quotes...or italics.
>
> Technically, email addresses are not case-sensentive, so we could
> capitalize them (e.g., Release and Project-Proposals).  But I'm unsure I
> would do this, as email addresses are almost always presented in lowercase
> and hence presenting uppercase could cause confusion.
>
>
> Kent
>

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