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

Actually, karaf in Helium is the *perfect* example of why KDC is crucial.

We *rushed* the Helium Simultaneous Release Plan out the door.  We did *not* KDC karaf for Helium.  We *did* make a series of commitments to figure stuff out at various other milestones.  We did not *actually* figure those things out at those milestones.  KDC is about *preventing* that kind of a problem in the future.  Its why its crucial.

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.

Again, the karaf issue was a *failure* to KDC when we should have because of a *rush* to get out a SR Plan.  I’d like us to *not* repeat that particular mistake again.

(note: much love to karaf, apologies to karaf that its being used for this example :( ).