Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Planning Council/October 6 2010"
(→Helios SR1) |
(→Helios SR1) |
||
Line 143: | Line 143: | ||
* One issue to document as feedback (that I have heard about from TPTP PMC/Planning Council Rep): EMF didn't deliver any maintenance until the day after RC4 +1 day [but, unclear to me is if that was just download zips or any form of delivered fixes, even in helios repo?] I think, it deserves repeating that communication is key. We all need to make an effort to keep others informed. The late (or last minute?) changes caused TPTP to have to do a lot of re-work and was made worse by there being no notice or announcement on cross-project list. I'm sure there's many things that could have been different, from all teams involved ... but just documenting this case as once example of the importance of keeping others informed. Not to mention, of course, that incremental delivery of fixes allows for better testing. I also suggested the TPTP team communicate more directly with EMF team either through their mailing list or cross-project list, to let them know when impacted, but I think in this case, by the time it was discovered there wasn't much to do. Anything we, as Planning Council, can do to help situations like this? Foster timely communication? | * One issue to document as feedback (that I have heard about from TPTP PMC/Planning Council Rep): EMF didn't deliver any maintenance until the day after RC4 +1 day [but, unclear to me is if that was just download zips or any form of delivered fixes, even in helios repo?] I think, it deserves repeating that communication is key. We all need to make an effort to keep others informed. The late (or last minute?) changes caused TPTP to have to do a lot of re-work and was made worse by there being no notice or announcement on cross-project list. I'm sure there's many things that could have been different, from all teams involved ... but just documenting this case as once example of the importance of keeping others informed. Not to mention, of course, that incremental delivery of fixes allows for better testing. I also suggested the TPTP team communicate more directly with EMF team either through their mailing list or cross-project list, to let them know when impacted, but I think in this case, by the time it was discovered there wasn't much to do. Anything we, as Planning Council, can do to help situations like this? Foster timely communication? | ||
− | * The build machine failure and slow recovery was nearly enough to derail the scheduled release. Not sure what more we can do, but glad to hear IT team will provide more support for build machine recovery (See {{bug|325969}}. | + | * The build machine failure and slow recovery was nearly enough to derail the scheduled release. Not sure what more we can do, but glad to hear IT team will provide more support for build machine recovery (See {{bug|325969}}). |
+ | * The mirrors were a bit overloaded with our "outflow" the day or two before, and had trouble "catching up". | ||
+ | : There is no longer any need to wait until "day before" for projects to put their artifacts in their final location, as long as leave "invisible" until the official release. Everyone waiting until the day before means the mirrors are very busy pulling content the day before, and have trouble getting caught up and in a steady state before the actual release. So, one action is to make sure everyone is properly educated about his. It might take some thing more formal ... some projects promote 5 days before, some 4 days before, some 3 days before, etc. Also, may need better directions on how to promote but leave invisible ... perhaps many projects wait and promote at last minute because they don't know how to do that?'' | ||
=== Maintenance Schedule === | === Maintenance Schedule === | ||
Revision as of 10:48, 6 October 2010
Contents
Logistics
Meeting Title: | Planning Council Conference Call |
Date & Time: | Wednesday, October 6, 2010, at 1600 UTC / 1200 Eastern |
Dial-in: | For the call-in numbers, see the "Project Review" number on Foundation Portal page. |
Attendees
PMC (and Strategic) Reps
Strategic Reps
Appointed
|
Inactive
|
Announcements
- ?
Helios SR1
- Any issues? complaints?
- One issue to document as feedback (that I have heard about from TPTP PMC/Planning Council Rep): EMF didn't deliver any maintenance until the day after RC4 +1 day [but, unclear to me is if that was just download zips or any form of delivered fixes, even in helios repo?] I think, it deserves repeating that communication is key. We all need to make an effort to keep others informed. The late (or last minute?) changes caused TPTP to have to do a lot of re-work and was made worse by there being no notice or announcement on cross-project list. I'm sure there's many things that could have been different, from all teams involved ... but just documenting this case as once example of the importance of keeping others informed. Not to mention, of course, that incremental delivery of fixes allows for better testing. I also suggested the TPTP team communicate more directly with EMF team either through their mailing list or cross-project list, to let them know when impacted, but I think in this case, by the time it was discovered there wasn't much to do. Anything we, as Planning Council, can do to help situations like this? Foster timely communication?
- The build machine failure and slow recovery was nearly enough to derail the scheduled release. Not sure what more we can do, but glad to hear IT team will provide more support for build machine recovery (See bug 325969).
- The mirrors were a bit overloaded with our "outflow" the day or two before, and had trouble "catching up".
- There is no longer any need to wait until "day before" for projects to put their artifacts in their final location, as long as leave "invisible" until the official release. Everyone waiting until the day before means the mirrors are very busy pulling content the day before, and have trouble getting caught up and in a steady state before the actual release. So, one action is to make sure everyone is properly educated about his. It might take some thing more formal ... some projects promote 5 days before, some 4 days before, some 3 days before, etc. Also, may need better directions on how to promote but leave invisible ... perhaps many projects wait and promote at last minute because they don't know how to do that?
Maintenance Schedule
SR2 Fourth Friday of February 2/25/2011
For detailed RC schedules, see Service Release Schedule in master plan
Helios Retrospective
Any additions?
Planning_Council/Helios_retrospective
Indigo Status
- M2 repo successfully created
- No M2 EPP packages
- And I've pestered Markus enough he's stopped returning my emails? :(
- 3 projects not in M2:
- jetty
- riena
- subversive
- Do they really intend to drop out? Or does this violate "once in always in"?
Indigo Plan and Schedule
Tracking "setup" required from Foundation in bug 321522
See initial Indigo Wiki page
Issues and Proposal for 3.7 versus 4.1
- See working notes in http://wiki.eclipse.org/Indigo/HowToAddress37And41Platform
Other business
- ?
ToDo Items
- ?
Next Meeting
November 3, 12 noon Eastern
Reference
Simultaneous Release Roles and Simultaneous Release Roles/EMO