On Oct 30, 2014, at 11:48 AM, Colin Dixon <colin@...> wrote:

So, it seems like M0 is almost meaningless. There's no requirements for projects and so it's date can be set arbitrarily. I was thinking that M0 would be some fixed time after the previous release just to note that we do, in fact, intend to have a next release.

We could alternately define M0 to be the date the TSC approves the release plan, but I'm not sure that's any more useful.

Does anyone else feel strongly about some meaning of M0 that I've missed?

--Colin

On Thu, Oct 30, 2014 at 12:30 PM, Ed Warnicke (eaw) <eaw@...> wrote:

Luis,

We haven’t crossed M0 yet, because the SR plan has not been approved by the TSC.

I am fundamentally opposed to approving a plan with Milestone dates in the past at 

time of approval.

Ed

On Oct 29, 2014, at 5:44 PM, Luis Gomez <ecelgp@...> wrote:

Hi Ed,

Without going into your detailed comments (I need more time for that) I sent mail last week saying all “KDC" requirements should be finalized and agreed by M1 the latest so that projects can work and deliver a good release plan candidate. What you say here is that these requirements should be there even before so that projects can choose whether or not they join the SR and I agree with that. Problem is, we already crossed M0, and we are 3 weeks away from M1, so when should we get a candidate for KDC requirements and when should we have this ready to handover to projects to decide on SR?

BR/Luis

On Oct 29, 2014, at 2:09 PM, Ed Warnicke (eaw) <eaw@...> wrote:

General Comments:

OMG this is so much improved over Helium/Hydrogen :)

Principles to Consider:

I would suggest that we consider the following principles in looking at the Simultaneous Release Plan:

1)  Requirements on Projects should be:

a) Known: by projects prior to opening of the Simultaneous Release (projects can’t commit to the unknown)

b) Doable: clear and tested instructions for how to accomplish them (requirements must be doable)

c) Confirmable: it should be clear how a project or a third party would know that a requirement is met

d)  I abbreviate this below as KDC.

e)  Based on a lot of confusion seen during Helium, I think part of K is being referenced in the ‘Requirements for Participation’ section not

just in the schedule or other sections (though I think listing there to is important).

2)  When considering new requirements I’d strongly council that we consider doing it in two phases:

a)  Reporting/Notification (RN): The first Simultaneous Release Plan in which we are looking at a new requirement,

we simply require reporting of whether it was done or not.  This allows us to find out whether the requirement

actually makes sense/works/is really doable.  It is a strong defense against us requiring something that sounds good

but turns out to be insane.

        b)  Requiring (Req):  If a Reporting/Notification requirement went well in the previous Simultaneous Release, we could the promote

it to a requirement in the subsequent ones.  We know it can be done (people did it and reported on it), we’ve sorted out

(hopefully) the kinks etc.

Detailed Comments:

1)  Definitions: 

a) I do not feel we have the necessary tooling to allow us to manage the Legacy/Tentative/Provisional distinction realistically.

I think developing that tooling and asking for folks to mark APIs by end of Lithium may be reasonable (if someone is willing to do the

tooling), but I do not think it is reasonable to ask folks to so by M1.  Perhaps this should be RN this time around.

b)  We also desperately need to be able to mark APIs ‘Internal’.  Not all API looking things are really meant of external consumption.  Accessibility is

      not the litmus test as one cannot reasonably control it.

c)  We had talked about rolling RCs… did any of that make it into the Plan?

d)  "Deadlines for Release Candidates (RC0, RC1 and RC1) and the release are the same regardless of offset. Deadlines for M1 and M2 are offset by +1 week and +2 weeks as no code is involved. Full details can be found in the dates listed in the Schedule table.” could we strike “as no code in involved”?  Bug fixes change code :)

2) Requirements for Participation:

a)  Could someone explain “All Milestone deliverables will be verified by the Lithium Release Management staff and/or the TSC” - I am confused as to what this means, could we get some clarification here?

I would find it very odd for *all* release deliverables to be verified… but I could imagine someone verifying things like ‘Yep, project Foo is reporting to Sonar’.  Also not clear on what the mechanism of verification

here is.  My gut is there is something very good under this sentence… but I’m not at all clear about it.  I suspect this could be made very very good by simply making it clear that someone should carry out the

confirmation (C in KDC) and record it.  Anyone *should* be able to C (Confirm) a requirement… but someone *should* and should record it :)

3) Schedule:

a ) I am uncomfortable with M0 (Lithium Open) proceeding actual finalization of the Simultaneous Release Plan, in part because of

b)  I feel strongly that we need to provide projects the full 4 week Milestone Period to sort out meeting their M1 obligations.

c)  ‘New Project Infra’:  This date seems very very very late in the game to me.  Especially with Holiday’s looming.  Could we define this as an SLA from project approval date?

      “SLA for provisioning of new project infra will be no later than 3 business days after project approval.  Verification of correct functioning of new project infra working for all committers shall happen no later

than 1 week after project creation.”  This way we can actually know we have infra and its working for the committers.  Also, I’d like us to work out how to make this KDC, and clearly tempered by reality with input from

the infra team.  I would say minimally though that every project must have working infra prior to M1.

d) M2:  I am deeply uncomfortable with “Documentation Project to Publish Documentation requirements for participating projects”.  If we want integration and documentation requirements for the Simultaneous Release Plan,

we need to get them up front as part of the plan, and have in hand the *how* of their accomplishment so that projects can know what they are signing up for an how to do it and how to know they’ve done it.

Basically, this fails KDC.

e) M3:  Could we get some clarity on "TENTATIVE APIs are declared go/no-go” ( I have no idea who declares this, what it means, how it is communicated, or what its import is)

(again, I suspect this is pure goodness, just underspecified ;) )  This kinda fails KDC.

f) M3: What is a documentation plan?  Do we have a template for it?  Unless I am mistaken, this fails KDC.

g) M3:  Could “Karaf features defined” be expanded to “Karaf features defined and included in integration”?  Or possible “Karaf features defined, OSGI tested (aka, they wire), and included in integration” ? (again, seeking a KDC here that matches our desired outcome :)

h) M3:  Could we make the requirements around Integration and System test plans KDC?

i) M5:  Could we set a date and time for RC[0-2] cutting up front?  Is there a reason not to?

j) M5: Could we add something about reporting to the blocking bugs spreadsheet here?  That was mega useful :)

  4) Participating Projects

Could we get the table of the fields we’d like listed in this section up front?  I suspect George could do something awesome here :)

  5) Communication Channels: 

a) Could we get this section in sync with the Leadership and Communication Section in Requirements for Participation?  

b) Could we consider starting up daily IRC meeting around the RC timeframe?  Not sure if we want to or not, but we have productively done so in the past.  Would like to call it out up front.

Ed

On Oct 22, 2014, at 7:14 PM, Colin Dixon <colin@...> wrote:

The draft release plan that Phil and I have been working on is ready for comments. You can find it here:
https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd

Some highlights:

* We use offsets with a delay of 2 between offsets for code deliverables

* Documentation, Integration, and Test are called out more explicitly and earlier

* Most of the lessons learned section is addressed with notes as to how [0]

Huge thanks to Phil for his help in this.

I've put a significant block of time aside on the agenda for the TSC call to go through it as well, but it's probably worth reading through before then as well.

Thanks,

--Colin

[0] https://wiki.opendaylight.org/view/Simultaneous_Release:DRAFT_Lithium_Release_Plan_ckd#Lessons_from_Hydrogen.2FHelium_that_Should_be_Applied

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

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