|
Kent Watsen <kwatsen@...>
Overall very good at defining "what", but less so at defining "how". For instance:
-
Planning
- Projects must declare their intent to participate in the Simultaneous Release by M1.
- How? Send email to "project-proposals" list with specific Subject line and, in the body of the email, a link to Lithium-compliant release plan? - in addition to also listing themselves under the "Participating Projects" section on this wiki page?
-
Leadership & Communication
- Each project must elect a Project Lead as described in the TSC charter
- Section 7 of the TSC charter describes voting, but missing from this section is a demonstrable output, such as the project lead's name being added to the projects main page's "Project Facts" boxes, and maybe send an email to a list declaring the choice
as well?
-
Meeting Deadlines
- If a project cannot make a deadline, the project lead must write a summary of what was missed? why? the course correction that will be taken? and it's impact on other projects?
- Is this summary to be posted to the Wiki, sent to a list, sent to just dependent projects, or all of the above?
- Cross Project Milestone and Release Candidate Reporting
- It is the responsibility of each projects Simultaneous Release Contact to report both positive and negative statuses
- How? - by sending email to "release"? - any specific subject line needed?
Nits:
-
Introduction
- OLD: This is a Simultaneous Release Plan for OpenDaylight.
- NEW: This is a Simultaneous Release Plan for the Lithium release of OpenDaylight.
-
Leadership & Communication
- OLD: Each project must elect a Project Lead as described in the TSC charter
- NEW: Each project must elect a Project Lead as described in the TSC charter, section 7.
-
Leadership & Communication
- OLD: The Project Lead will be subscribed to the release mailing list and must respond to requests send to the a timely fashion
- NEW: The Project Lead will be subscribed to the "release" mailing list and must respond to requests sent to it in a timely fashion
- Service Release Participation
- OLD: All projects participating in the release are also required to participate in the stability releases after the formal release
- NEW: All projects participating in the release are also required to participate in the stability releases after the formal release (please see Lithium_Service_Release_Expectations for
details)
- Meeting Deadlines
- OLD: If a project cannot make a deadline, the project lead must write a summary of what was missed? why? the course correction that will be taken? and it's impact on other projects?
- NEW: If a project cannot make a deadline, the project lead must write a summary of what was missed and why, the course correction that will be taken, and it's impact on other projects.
- Bugs
- OLD: Bugs should be filed in Bugzilla
- NEW: Bugzilla is used to track all bugs in OpenDaylight. Bugs must be filed for the appropriate project.
Thanks,
Kent
|
|
|
Thanks Kent! I'll make these edits, but put them here as well. Comments inline. (Sorry for messing up the formatting, but I had to for inline comments.) I guess the high-order bit is that we should define how milestone readouts are sent and with what subject's. --Colin On Fri, Oct 31, 2014 at 3:39 PM, Kent Watsen <kwatsen@...> wrote:
Overall very good at defining "what", but less so at defining "how". For instance:
Planning
Projects must declare their intent to participate in the Simultaneous Release by M1.
How? Send email to "project-proposals" list with specific Subject line and, in the body of the email, a link to Lithium-compliant release plan? - in addition to also listing themselves under the "Participating Projects" section on this wiki page?
To participate, you must e-mail your candidate release plan to the release list on M1. I'll make the edit. Leadership & Communication
Each project must elect a Project Lead as described in the TSC charter
Section 7 of the TSC charter describes voting, but missing from this section is a demonstrable output, such as the project lead's name being added to the projects main page's "Project Facts" boxes, and maybe send an email to a list declaring the choice as well? +1 I'll add a note saying to (i) update the project facts template for the project, (ii) update the participating projects table of this release, and (iii) e-mail the <project>-dev, release, and tsc lists. (We really also need a place to describe the process in general, separate from a release plan.) Meeting Deadlines
If a project cannot make a deadline, the project lead must write a summary of what was missed? why? the course correction that will be taken? and it's impact on other projects?
Is this summary to be posted to the Wiki, sent to a list, sent to just dependent projects, or all of the above? Good point. It should (at least) be part of the readout projects send to the release list at every milestone. It should also maybe go on the wiki. Cross Project Milestone and Release Candidate Reporting
It is the responsibility of each projects Simultaneous Release Contact to report both positive and negative statuses
How? - by sending email to "release"? - any specific subject line needed? Sending to release, but good point. Nits:
Introduction
OLD: This is a Simultaneous Release Plan for OpenDaylight.
NEW: This is a Simultaneous Release Plan for the Lithium release of OpenDaylight. Sure. Leadership & Communication
OLD: Each project must elect a Project Lead as described in the TSC charter
NEW: Each project must elect a Project Lead as described in the TSC charter, section 7. Sure. Leadership & Communication
OLD: The Project Lead will be subscribed to the release mailing list and must respond to requests send to the a timely fashion
NEW: The Project Lead will be subscribed to the "release" mailing list and must respond to requests sent to it in a timely fashion I'm curious what the logic is here? Is it to make it italics or bold? Service Release Participation
OLD: All projects participating in the release are also required to participate in the stability releases after the formal release
NEW: All projects participating in the release are also required to participate in the stability releases after the formal release (please see Lithium_Service_Release_Expectations for details) Sure. Meeting Deadlines
OLD: If a project cannot make a deadline, the project lead must write a summary of what was missed? why? the course correction that will be taken? and it's impact on other projects?
NEW: If a project cannot make a deadline, the project lead must write a summary of what was missed and why, the course correction that will be taken, and it's impact on other projects. Sure. Bugs
OLD: Bugs should be filed in Bugzilla
NEW: Bugzilla is used to track all bugs in OpenDaylight. Bugs must be filed for the appropriate project. Sure.
|
|
|
Kent Watsen <kwatsen@...>
Leadership & Communication
OLD: The Project Lead will be subscribed to the release mailing list
and must respond to requests send to the a timely fashion
NEW: The Project Lead will be subscribed to the "release" mailing list
and must respond to requests sent to it in a timely fashion I'm curious what the logic is here? Is it to make it italics or bold?
It's a nit, admittedly, but I've always felt that references to lowercase names should be in quotes...or italics. Technically, email addresses are not case-sensentive, so we could capitalize them (e.g., Release and Project-Proposals). But I'm unsure I would do this, as email addresses are almost always presented in lowercase and hence presenting uppercase could cause confusion. Kent
|
|
|
Fair enough, maybe I should make them in typewriter <tt>.
--Colin
On Mon, Nov 3, 2014 at 12:47 PM, Kent Watsen <kwatsen@...> wrote:
>>Leadership & Communication
>>
>> OLD: The Project Lead will be subscribed to the release mailing list
>>and must respond to requests send to the a timely fashion
>> NEW: The Project Lead will be subscribed to the "release" mailing list
>>and must respond to requests sent to it in a timely fashion
>
>I'm curious what the logic is here? Is it to make it italics or bold?
It's a nit, admittedly, but I've always felt that references to lowercase
names should be in quotes...or italics.
Technically, email addresses are not case-sensentive, so we could
capitalize them (e.g., Release and Project-Proposals). But I'm unsure I
would do this, as email addresses are almost always presented in lowercase
and hence presenting uppercase could cause confusion.
Kent
|
|
|
Kent Watsen <kwatsen@...>
Even more useful, make them hyperlinks :)
From: Colin Dixon < colin@...>
Date: Monday, November 3, 2014 at 2:33 PM
To: Kent Watsen < kwatsen@...>
Cc: " tsc@..." < tsc@...>
Subject: Re: [OpenDaylight TSC] review of DRAFT_Lithium_Release_Plan_ckd
Fair enough, maybe I should make them in typewriter <tt>.
--Colin
toggle quoted message
Show quoted text
>>Leadership & Communication
>>
>> OLD: The Project Lead will be subscribed to the release mailing list
>>and must respond to requests send to the a timely fashion
>> NEW: The Project Lead will be subscribed to the "release" mailing list
>>and must respond to requests sent to it in a timely fashion
>
>I'm curious what the logic is here? Is it to make it italics or bold?
It's a nit, admittedly, but I've always felt that references to lowercase
names should be in quotes...or italics.
Technically, email addresses are not case-sensentive, so we could
capitalize them (e.g., Release and Project-Proposals). But I'm unsure I
would do this, as email addresses are almost always presented in lowercase
and hence presenting uppercase could cause confusion.
Kent
|
|
|
Ed Warnicke (eaw) <eaw@...>
Colin,
Per the discussion about leaving adequate time M0->M1 and M1->M2, I wanted to throw out some
concrete date proposals.
I think you’ve expressed agreement that M0 should start from roughly when we
approve the SR Plan (which we are hoping to do this Thursday). For sake of discussion, I wanted
to make a concrete date proposal (all dates for which offsets apply are offset 0 dates, with the 2 week
and 4 week add for offset 1 and offset 2 respectively:
M0 :11/7/2014
Last Date for new Projects: Nov 27 (offset0)
M1 12/12/2014 ( 1 extra week for Thanksgiving )
M2: 1/23/2015 ( 2 extra weeks for Christmas)
M3: 2/20/2015
M4: 3/20/2015
M5: 4/17/2015
RC0: 5/29/2015
RC1: 6/12/2015
RC2: 6/26/2015
Formal Release: 7/3/2015
SR1: 8/14/2015
SR2: 9/25/2015
Thoughts?
Ed
toggle quoted message
Show quoted text
On Nov 3, 2014, at 12:47 PM, Kent Watsen <kwatsen@...> wrote:
Leadership & Communication
OLD: The Project Lead will be subscribed to the release mailing list
and must respond to requests send to the a timely fashion
NEW: The Project Lead will be subscribed to the "release" mailing list
and must respond to requests sent to it in a timely fashion I'm curious what the logic is here? Is it to make it italics or bold?
It's a nit, admittedly, but I've always felt that references to lowercase
names should be in quotes...or italics.
Technically, email addresses are not case-sensentive, so we could
capitalize them (e.g., Release and Project-Proposals). But I'm unsure I
would do this, as email addresses are almost always presented in lowercase
and hence presenting uppercase could cause confusion.
Kent
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
|
|
|
So, in essence, this is just moving M1 out so that there are four weeks (plus an extra week to account for Thanksgiving) after this week for projects to meet the M1 dates. I have a more detailed scanning of the proposal with a few questions below, but I still want to push back on the need to do this.
The core reason I've heard for moving the M1 date out (so far only from Ed) has been to allow for the development of better per-project release plans. I think that moving M1 out is actually going to lead to WORSE, not better release plans for most projects.
In Helium, my observation was that most projects put together the most basic release plan they could just before the M1 milestone because that was all that was required. Unless we put extra requirements on the candidate release plans, and likely even if we do, I would expect this to happen again.
If we really want to improve the per-project release plans, I think we need to do something akin to the Karaf happy hour where we review and help projects improve their release plans, particularly in the area of cross-project needs. To do that, we really need projects to have at least a candidate release plan, which means it MUST happen after M1, so we should make M1 as soon as we feasibly can with the intent of using the time between M1 and M2 to actively improve release plans.
My proposal would be to leave the dates where they are and instead provide weekly release plan review sessions (similar to release review, but hopefully with more feedback) between M1 and M2. I'd like to avoid adding extra time, but IF we want to, it should be between M1 and M2.
--Colin
===
I'm just reiterating what you had with differences from the current draft (in weeks) here:
n/a M0: 11/7/2014
+~3 Last Date for new Projects: Nov 27 (offset0)
+3 M1 12/12/2014 ( 1 extra week for Thanksgiving )
+2 M2: 1/23/2015 ( 2 extra weeks for Christmas)
+2 M3: 2/20/2015
+2 M4: 3/20/2015
+2 M5: 4/17/2015
+2 RC0: 5/29/2015
+2 RC1: 6/12/2015
+2 RC2: 6/26/2015
+1 Formal Release: 7/3/2015
+0 SR1: 8/14/2015
+0 SR2: 9/25/2015
Looking at things, you've adjusted M0 to have the new definition that it must come after the release plan is approved and then moved all the other dates forward two weeks except for:
1.) M1 and last date for new projects are by 3 weeks since they fall after thanksgiving, whereas before they do not
2.) The formal release is only moved forward by 1 week 3.) The stable updates are not moved Was that the intent? It seems like we should move the stable updates back by just as much as the formal release. It's also not clear to me why we move the formal release plan out less than everything else.
On Mon, Nov 3, 2014 at 2:59 PM, Ed Warnicke (eaw) <eaw@...> wrote: Colin,
Per the discussion about leaving adequate time M0->M1 and M1->M2, I wanted to throw out some
concrete date proposals.
I think you’ve expressed agreement that M0 should start from roughly when we
approve the SR Plan (which we are hoping to do this Thursday). For sake of discussion, I wanted
to make a concrete date proposal (all dates for which offsets apply are offset 0 dates, with the 2 week
and 4 week add for offset 1 and offset 2 respectively:
M0 :11/7/2014
Last Date for new Projects: Nov 27 (offset0)
M1 12/12/2014 ( 1 extra week for Thanksgiving )
M2: 1/23/2015 ( 2 extra weeks for Christmas)
M3: 2/20/2015
M4: 3/20/2015
M5: 4/17/2015
RC0: 5/29/2015
RC1: 6/12/2015
RC2: 6/26/2015
Formal Release: 7/3/2015
SR1: 8/14/2015
SR2: 9/25/2015
Thoughts?
Ed
> On Nov 3, 2014, at 12:47 PM, Kent Watsen < kwatsen@...> wrote:
>
>
>
>>> Leadership & Communication
>>>
>>> OLD: The Project Lead will be subscribed to the release mailing list
>>> and must respond to requests send to the a timely fashion
>>> NEW: The Project Lead will be subscribed to the "release" mailing list
>>> and must respond to requests sent to it in a timely fashion
>>
>> I'm curious what the logic is here? Is it to make it italics or bold?
>
>
> It's a nit, admittedly, but I've always felt that references to lowercase
> names should be in quotes...or italics.
>
> Technically, email addresses are not case-sensentive, so we could
> capitalize them (e.g., Release and Project-Proposals). But I'm unsure I
> would do this, as email addresses are almost always presented in lowercase
> and hence presenting uppercase could cause confusion.
>
>
> Kent
>
> TSC mailing list
> TSC@...
> https://lists.opendaylight.org/mailman/listinfo/tsc
|
|
|
Ed Warnicke (eaw) <eaw@...>
I think the net-net is this:
M1 bumps back 2 weeks (+1 week for holidays for a total of 3… but we are eating the holiday offsets no matter what, so only effectively 2 weeks)
Final Lithium Release bumps back 1 week
On net we gain:
a) Time for projects to bring high quality initial Release Plans for M1 so they can work cross project for M2
b) Time alignment for M2 such that we could easily organize a Hackfest between M1 and M2 in January to get folks collaborating together
On net we loose:
1 week net. We release 1 week later overall.
Ed
On Nov 3, 2014, at 4:35 PM, Colin Dixon < colin@...> wrote:
So, in essence, this is just moving M1 out so that there are four weeks (plus an extra week to account for Thanksgiving) after this week for projects to meet the M1 dates. I have a more detailed scanning of the proposal with a few questions below,
but I still want to push back on the need to do this.
The core reason I've heard for moving the M1 date out (so far only from Ed) has been to allow for the development of better per-project release plans. I think that moving M1 out is actually going to lead to WORSE, not better release plans for most projects.
In Helium, my observation was that most projects put together the most basic release plan they could just before the M1 milestone because that was all that was required. Unless we put extra requirements on the candidate release plans, and likely even if we
do, I would expect this to happen again.
If we really want to improve the per-project release plans, I think we need to do something akin to the Karaf happy hour where we review and help projects improve their release plans, particularly in the area of cross-project needs. To do that,
we really need projects to have at least a candidate release plan, which means it MUST happen after M1, so we should make M1 as soon as we feasibly can with the intent of using the time between M1 and M2 to actively improve release plans.
My proposal would be to leave the dates where they are and instead provide weekly release plan review sessions (similar to release review, but hopefully with more feedback) between M1 and M2. I'd like to avoid adding extra time, but IF we want
to, it should be between M1 and M2.
--Colin
===
I'm just reiterating what you had with differences from the current draft (in weeks) here:
n/a M0: 11/7/2014
+~3 Last Date for new Projects: Nov 27 (offset0)
+3 M1 12/12/2014 ( 1 extra week for Thanksgiving )
+2 M2: 1/23/2015 ( 2 extra weeks for Christmas)
+2 M3: 2/20/2015
+2 M4: 3/20/2015
+2 M5: 4/17/2015
+2 RC0: 5/29/2015
+2 RC1: 6/12/2015
+2 RC2: 6/26/2015
+1 Formal Release: 7/3/2015
+0 SR1: 8/14/2015
+0 SR2: 9/25/2015
Looking at things, you've adjusted M0 to have the new definition that it must come after the release plan is approved and then moved all the other dates forward two weeks except for:
1.) M1 and last date for new projects are by 3 weeks since they fall after thanksgiving, whereas before they do not
2.) The formal release is only moved forward by 1 week
3.) The stable updates are not moved
Was that the intent? It seems like we should move the stable updates back by just as much as the formal release. It's also not clear to me why we move the formal release plan out less than everything else.
|
|
|
My (slightly different) reading of the net-net is:
* M1–RC2 shift back by two weeks (or 3 in one case because of holidays)
* Final release shifts back by 1 week (you sacrifice a week of time between RC2 and final release vs. whats in the draft)
* Stable updates don't shift at all (for reasons I don't entirely understand)
I see two possible advantages to this: 1.) Projects get two extra weeks to work on the release plans before having to post a candidate one. 2.) It makes it so we have a chance to have a mid-Jan hackfest before M2.
I find both to be somewhat weak advantages.
As far as extra time for project release plans, it's not as if it wasn't clear that there was going to be a Lithium release and that it was going to involve things like API freezes, code freezes, documentation, testing, and the whole nine yards. I find it hard to believe that projects were sitting on their hands just waiting for the TSC to approve the release plan for them to start thinking about what they wanted to do in Lithium.
Maybe you could argue that for newer projects, but in those cases, they will almost certainly be joining at offset 1 and offset 2, so will have at least four weeks between M0 and M1 assuming we approve the dates currently on the draft on Monday.
As far as hackfest planning goes, I've been talking with Phil and the LF people and they say that finding a venue in the Bay Area for 100+ people in mid-January will likely be hard and attendance is low when they are held outside the bay area. The talk is of maybe having a distributed hackfest with local clusters gathering in member-company-provided spaces. If we do that, I think the advantage of moving dates out for this purpose rather than using our normal methods of interaction seems pretty low.
I just want to note that I really do like the idea of having weekly (or maybe even more frequent) meetings on IRC, G+ hangout, WebEx, and whatever else to review and collaborate on projects' release plans between M1 and M2. I think that will be hugely beneficial.
*If* we do move dates back, I'd really rather see us keep the current gaps between M5, RC0, RC1, RC2, and Release rather than shrinking them. Losing a week of testing at the end is not free.
Cheers,
On Fri, Nov 7, 2014 at 4:00 PM, Ed Warnicke (eaw) <eaw@...> wrote:
I think the net-net is this:
M1 bumps back 2 weeks (+1 week for holidays for a total of 3… but we are eating the holiday offsets no matter what, so only effectively 2 weeks)
Final Lithium Release bumps back 1 week
On net we gain:
a) Time for projects to bring high quality initial Release Plans for M1 so they can work cross project for M2
b) Time alignment for M2 such that we could easily organize a Hackfest between M1 and M2 in January to get folks collaborating together
On net we loose:
1 week net. We release 1 week later overall.
Ed
On Nov 3, 2014, at 4:35 PM, Colin Dixon < colin@...> wrote:
So, in essence, this is just moving M1 out so that there are four weeks (plus an extra week to account for Thanksgiving) after this week for projects to meet the M1 dates. I have a more detailed scanning of the proposal with a few questions below,
but I still want to push back on the need to do this.
The core reason I've heard for moving the M1 date out (so far only from Ed) has been to allow for the development of better per-project release plans. I think that moving M1 out is actually going to lead to WORSE, not better release plans for most projects.
In Helium, my observation was that most projects put together the most basic release plan they could just before the M1 milestone because that was all that was required. Unless we put extra requirements on the candidate release plans, and likely even if we
do, I would expect this to happen again.
If we really want to improve the per-project release plans, I think we need to do something akin to the Karaf happy hour where we review and help projects improve their release plans, particularly in the area of cross-project needs. To do that,
we really need projects to have at least a candidate release plan, which means it MUST happen after M1, so we should make M1 as soon as we feasibly can with the intent of using the time between M1 and M2 to actively improve release plans.
My proposal would be to leave the dates where they are and instead provide weekly release plan review sessions (similar to release review, but hopefully with more feedback) between M1 and M2. I'd like to avoid adding extra time, but IF we want
to, it should be between M1 and M2.
--Colin
===
I'm just reiterating what you had with differences from the current draft (in weeks) here:
n/a M0: 11/7/2014
+~3 Last Date for new Projects: Nov 27 (offset0)
+3 M1 12/12/2014 ( 1 extra week for Thanksgiving )
+2 M2: 1/23/2015 ( 2 extra weeks for Christmas)
+2 M3: 2/20/2015
+2 M4: 3/20/2015
+2 M5: 4/17/2015
+2 RC0: 5/29/2015
+2 RC1: 6/12/2015
+2 RC2: 6/26/2015
+1 Formal Release: 7/3/2015
+0 SR1: 8/14/2015
+0 SR2: 9/25/2015
Looking at things, you've adjusted M0 to have the new definition that it must come after the release plan is approved and then moved all the other dates forward two weeks except for:
1.) M1 and last date for new projects are by 3 weeks since they fall after thanksgiving, whereas before they do not
2.) The formal release is only moved forward by 1 week
3.) The stable updates are not moved
Was that the intent? It seems like we should move the stable updates back by just as much as the formal release. It's also not clear to me why we move the formal release plan out less than everything else.
|
|
|
