Re: draft lithium release plan
Ed Warnicke (eaw) <eaw@...>
Comments inline… with some snipping where I think we are violently agreeing ;)
I would suggest that if we can’t KDC it prior to approval of the SR, we shouldn’t require it.
Now that you say it that way… I agree :)
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”
?
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.
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).
I would also say that at a minimum all projects need to have working infra prior to M1.
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.
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.
Could we get a proposed improved wording?
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.
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 started to draft language, and then realized I am not entirely sure how the offsets interact with the Developer Meeting timing, do we know?
Ed
|
|