ability to requirements after TSC approval of the Lithium release plan

Colin Dixon

(Starting this discussion as it's own thread.)

My worry is that, like Karaf [0], we will end up with something that every project will really need to do and which can be made KDC, but that wasn't defined in the approved release plan. In that case, it actually may be *less* work for *everyone*, including projects, to meet the new requirement than to not.

Ed, I don't think taking more time to lay out the release plan for Helium would have fixed the Karaf issue. I think that, as in this case, there are likely to be things that we only find are problematic as we progress and explicitly disallowing us from having a way to deal with that is likely a bad idea.

I do think we should:
1.) discourage adding requirements in this way
2.) hold any such added requirements to a higher standard than KDC including:
     a.) being KDC
     b.) being reasonable in terms of time requirements from projects
     c.) encouraging projects to provide *early* feedback about difficulties so the requirements can be adjusted if needed

Along those lines, we are trying to define the integration/test and docs requirements *now*, but I'd also like to keep open the possibility to add a simple requirement that will make the release hugely smoother.


[0] I agree with Ed that we did not do a good job of making adopting Karaf KDC at first, but I *do* feel like we eventually got it to the point that it was KDC and it was critical to the release.

On Fri, Oct 31, 2014 at 3:41 PM, Ed Warnicke (eaw) <eaw@...> wrote:

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

Join {TSC@lists.opendaylight.org to automatically receive all group messages.