On Oct 31, 2014, at 2:20 PM, Colin Dixon <colin@...> wrote:

Inline, also with snips where we agree.

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

Comments inline… with some snipping where I think we are violently agreeing ;)

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

Comments inline.

On Wed, Oct 29, 2014 at 5: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.

+1 to this as guiding principles and goals.

However, I think over-striving for KDC now, especially for later milestones, will have the frustrating property that we will be specifying things now that are likely to be missing the point by the time we get there and also delay our ability to start working on the things we *do* understand in the earlier milestones.

I would suggest that if we can’t KDC it prior to approval of the SR, we shouldn’t require it.

Again, while I'm 100% in favor of these ideals, I just want to make sure that we don't shoot ourselves in the foot in terms of our ability to drive a successful release and adapt as we figure more things out.

Along those lines, if we end up with a task which is both KDC and reasonable for projects to accomplish, but only after the release plan has been approved, do we really want to make it so that we cannot require it? The example from Helium would be Karaf support. It's a good example for a bunch of reasons:
1.) it illustrates what KDC means as we didn't get it to KDC until Ed wrote up the Karaf step-by-step guide
2.) it illustrates how important it can be to be able to impose such a requirement as I don't know how we would have shipped Helium without projects adding Karaf support

3.) it illustrates how the TSC can respond to such requirements in flexible manner based on project feedback as we exempted Defense4All from needing to be in Karaf because it wasn't ever an OSGi bundle

I think that leaving open the possibility that we might add additional requirements (as long as they are reasonable, KDC, and will be flexibly enforced based on project feedback) is likely a good idea. This isn't to say that I want to do this, but that reserving this right and judiciously using it has the potential to make the release easier both in general and specifically for projects.

 

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.

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.

 

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?

 

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.

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.

 

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.

So, discussing the SLA is probably a good topic, but would really need to be done with interaction from the infra team as you say.

I would also say that at a minimum all projects need to have working infra prior to M1.

We can't do that because projects can, and likely will, have their creation review on the M1 date. That is that we can't *start* setting up their infra until after M1.

As it stands, the date iss set to one week (modulo thanksgiving) after M1 which seems as aggressive as we can be given how things work. If we want to change this so that you must have creation review before M1 for the Beryllium release.

 

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.

So, I'm less uncomfortable than you are and I think it's just that I have faith that the community will find and/or negotiate reasonable (and not onerous) approaches to docs and integration/test, but that those are likely to be somewhat fluid during this release as we struggled with them during Helium.

I think if we are serious here, we should ask Documentation and Integration to make proposals.  In particular, the TSC sets these requirements, under advisement from those projects.  And I am *deeply* concerned about those requirements

being KDC so projects can do reasonable plans.  The requirements for Documentation and Integration could *deeply* effect scope of effort and thus project Release Plan decisions for the candidate Release Plan at M1.

I’ve done a lot of Release Planning at the project level, I personally would not feel comfortable issuing a Release Plan at M1 without knowing the requirements by M0 so we could figure out who is going to do what and thus what can

reasonably be put on the plan at what Milestone.

As discussed on the TSC, we'll reach out to those groups and see what we can do this week.

We can try to move this to M1, which would give projects 4 weeks to incorporate them into their final release plans, but I'm not sure that we'll have the information and answers we'd like to by then. That is, I'm expecting that the documentation and integration/test groups will be extending tooling and adapting process during the release and they should be able to do that.

We need M1 to M2 for inter project planning… M0 to M1 gives us space for intra-project planning.  Without knowing those things at M0, you can’t do the intra-project planning for M1.

We have to get better at our project level Release Planning, and at inter project interaction around it… effectively collapsing the process makes it harder, not easier.

See above.
 

 

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.”

 

 

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?

 

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

Integration/test plan: Luis and the integration group have already committed to trying to work here and produce something people are happy with.

 

 

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

If we define RCs to be containing all the projects participating in the release, then this is not a date-based milestone, but based on where the projects are as we approach the targeted date. Perhaps we could declare a target date time. We have a date there, we could just add a time? Midnight UTC between the listed date and the next day? 

I think there’s an interesting discussion here.  A *huge* amount came together because of the TSC setting the RC1 as a drop dead… I am concerned that not making these date-based milestones will lead to continuous slipping.

It is a kindness to the projects to set that expectation up front, rather than bringing it in last minute (as I suspect we’d have to just to get out the door).

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?

 

 

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

+1 to this. I also think that we should have a described bugzilla profile for blocking bugs.

 

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

+1 George, can you do this?
 

  5) Communication Channels: 

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

Good ideas. I'll try to fold this in. (Or you could.)

 

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.

I agree this is a good idea. Do you have sample language?

I started to draft language, and then realized I am not entirely sure how the offsets interact with the Developer Meeting timing, do we know?

I put something in which was just there to make sure projects (and others) were aware. What I wrote was this: "During the RC process regular, e.g., daily, meetings will be held on IRC to identify and address critical issues as they arise.”

--Colin