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 :)

Fair enough. I was trying to provide explanations for why things were the way they were, but it's true that this one isn't technically correct even if the spirit is right. We probably do need some kind of meta-release-plan page which contains things like our guiding principles and the reasoning behind certain timings.

 

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 :)

Your gut feeling here is right. The intent was to put responsibility on the release management staff and/or TSC to actually do the C. That is "someone should and record it.”

I think we also need to be a little more careful here, because most *deliverables* are not the ones the TSC is requiring, but the content the projects are specifying themselves.

Perhaps:

“Each projects meeting of Requirements for Participation at each Milestone will be confirmed and recorded by the Lithium Release Management Team and/or the TSC”

?

At the point that a deliverable is listed with a milestone on a release plan, my take is that we really do want somebody to note if it was accomplished or not.

OK… I think that’s part of the Milestone Reporting by the projects.  I know when I did Milestone Reporting at least for controller that was done.

Admittedly, it is difficult for the TSC or release staff to evaluate project's deliverables if they are internal to the project. However, we'd still like to know even if via self-reporting. We can also get some information by asking for projects that depend on others to give readouts on if their needs were met.

I think the most that the TSC or Release staff can do is confirm that the *projects* reported on their content deliveries at Milestones… which I think is actually goodness :)

 

3) Schedule:

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

That was just unchanged from the original plan because M0 literally had no meaning. In my mind M0 should really be the day after the previous release or just removed from the release plan altogether.

M0 does have a meaning, its the opening of the SR… its when projects know what they will need to do to participate, and can start doing the work for what they have to do for M1.

I think I'm fine with having the definition be that "M0 is no sooner than when the TSC formally approves the release plan and provides adequate time for projects to decide if they can meet the requirements and declare their intent to participate by M1." Does that make sense?

Totally, as long as M1 comes no less than 4 weeks after that :)

 

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

I guess I disagree. M1 is almost a noop to prepare for M2.

M1 requires projects to elect their Project Leads, Prepare a Candidate Release Plan, etc… doing those things in a *meaningful* way is work, far from a noop.

(in particular, doing a quality candidate release plan is *hard*… and you *really* need to do that by M1 so that there can be the broader discussion between M1 and M2 with other

projects in the community).

Let me take this in two parts:

1.) The stuff other than the release plan: I think 2 weeks is more than enough for it.

I disagree.

2.) The release plan: I agree that good ones are hard, but as it stands we currently don't require "good" release plans at M1. If we want to add more requirements on the quality of release plans at M1 beyond existence, then maybe we need to push it.

A huge amount of suffering has come in the past of *not* having good ones at M1… I think we really need to *strive* for good ones at M1.  The ‘lets just throw something over the wall for the release plan’ has been a problem in the past, 

and I prefer we not encourage it by being cavalier here.

 

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.

The intent here was just for projects to either commit to providing the TENTATIVE APIs or declare that they weren't going to be able to provide them in this release and others should not count on them at this point. Agree that we should be more precise on what they output is and how to verify it.

Could we get a proposed improved wording?

Does this work?

"Projects will report whether they intend to deliver each of their TENTATIVE APIs in this release or not. Where TENTATIVE APIs are not going to be delivered, the projects that were looking to use them should utilize the part of their release plan that covered that contingency.”

I think I see where you are going here… M3 being functionality freeze, I think that is probably the appropriate place for it.  I’d suggest we work out a column in the Release Plan template for projects though to mark it :)

 

 

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 :)

See the above comment. I agree on all these points and think that we need supporting templates, checklists, tutorials, and/or guidelines, but I'm less convinced we need these to be fully KDC before we start moving toward M1 (which I see as mostly a noop) and onto M2.

Again, all of this feels very much like we are renaming M0 to M1, M1 to M2, and simply eliminating the inter-project cross planning step.  I think we need these by M0, and M0 *must* come after the date of SR Plan approval.

Docs plan: We're going to try to get what we can by this Thursday and see if we can have something people are happy with.

:)

Karafs features defined: +1 to what you say. Can we do that and link to the Karaf step-by-step guide

Seems reasonable

I added notes for the RCs saying this "The build for RCX will start at midnight UTC between <date-listed> and <day-after-date-listed>". I think that's probably right. Does that help?

Could you help me understand the reasoning in giving a 24 hours spread instead of a datetime certain?