Re: draft lithium release plan
|
Colin Dixon
Comments inline. On Wed, Oct 29, 2014 at 5:09 PM, Ed Warnicke (eaw) <eaw@...> wrote:
+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.
It sounds like we should discuss this a bit more. To be clear, the final release plan for projects is due at M2, which might help. We also have an exception process if we realize something got screwed up. I guess I'd err on the side of seeing if we can get this to work rather than pushing off figuring out what APIs we have and how they're changing again.
Does that actually need to be in the plan? It's something I think we should do, but it seemed like something that didn't require actions from projects in a concrete way, so it's not there now.
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.
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."
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.
I guess I disagree. M1 is almost a noop to prepare for M2.
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.
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. 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.
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.
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.
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?
+1 to this. I also think that we should have a described bugzilla profile for blocking bugs.
+1 George, can you do this?
Good ideas. I'll try to fold this in. (Or you could.)
|
|
|