Planning Council/October 6 2010
|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.|
PMC (and Strategic) Reps
- 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?
SR2 Fourth Friday of February 2/25/2011
For detailed RC schedules, see Service Release Schedule in master plan
Any additions? No additions. Move to reference section.
- M2 repo successfully created [discovered after meeting I forgot to promote! Done now]
- No M2 EPP packages
- And I've pestered Markus enough he's stopped returning my emails? :(
- 3 projects not in M2:
- Do they really intend to drop out? Or does this violate "once in always in"?
- Tom with discuss with jetty and riena, Wayne and/or Chris to discuss with subversive
Indigo Plan and Schedule
Tracking "setup" required from Foundation in bug 321522
See initial Indigo Wiki page
Review: There is a subtle implication of specifying Java 6 as "minimum runtime" requirement. Currently, we require contributors to use Java 5 when using pack200, since if not, and if involves a jar that contains no Java (e.g. source or documentation) then it can not be unpacked with Java 5, Java 6 would be required. This has been a headache for people since for many it means tweaking build scripts so an "old" (1.5) VM is used for that one step. During aggregation, we purposely use Java 5 to catch errors in this regard. For Indigo, I propose we not worry about being consistent here, and just use Java 6 during aggregation. Some projects may still want to use 1.5 VMs to do their pack200 ... if their adopters want it ... but I see no reason for mass consistency here ... if Java 6 is assumed to be minimum runtime VM. Any issues? Dissent?
- Some concern expressed, but mostly a matter of letting people know and documenting options. For example, for projects that want compatibility with VMs less than 1.6, they still can, of course, but will no longer get "built in" test from aggregation. Plus, should make clear, even a VM less than 1.6 can still use a pack200 (or, an unpack200 executable) from another VM, such as a 1.6 distribution, and specify it on their command line using
Issues and Proposal for 3.7 versus 4.1
- See working notes in http://wiki.eclipse.org/Indigo/HowToAddress37And41Platform
November 3, 12 noon Eastern