Difference between revisions of "Planning Council/October 6 2010"

Latest revision as of 15:27, 6 October 2010

Logistics

Attendees

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?

Ed said they will communicate better in future.

• 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? No additions. Move to reference section.

Planning_Council/Helios_retrospective

Indigo Status

• 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:

jetty

riena

subversive

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

Indigo Requirements

Suggestions during meeting:

• Make explicit that to be in repo, feature includes must be strict, so installs or builds are reproducible. (Even if there might eventually be improvements that allow additional features, with loose constraints ... but "minimum" requirement is the strict inclusion. Unclear what loose requirement solution will be. Note: the strict requirements are the way things are currently done ... just best to make explicit, since it has come up before.

• Move capabilities to "good citizen" section (and check wording to make clear that to document "not supported" is one option ... or, possibly "we don't know what this means" :).

• Consistent license. No real change to requirement, but should provide pointers to bugs where standard "user agreement" may change (to include EDL) and where p2 may be improved to allow pointer to URI ... or something.

• Add a "must do" to be in EPP package, must run on/test on Eclipse 3.7.

• Add a "should do" to have a 4.1 theme item in plan to describe what project is doing for 4.1 (and give some examples).

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 -Dorg.eclipse.update.jarprocessor.pack200.

Issues and Proposal for 3.7 versus 4.1

• See working notes in http://wiki.eclipse.org/Indigo/HowToAddress37And41Platform

Other business

• We were reminded Mylyn is Top Level project now, and we should be sure to invite rep to Planning Council.

• John mentioned Platform may drop Motif support from swt ... decision not final yet, and not sure if it effects any adapters or members ... just giving a heads up

ToDo Items

• Note from Wayne, to Wayne: (actually from last meeting) Remember to review plans starting after M4 (at latest) so questions can be clarified before "road map" produced.

• Wayne teased us all with promise of new tools to check CQs against downloads, which we projects can use ourselves ... but he wasn't ready to tell us about them today and he'll be saying more over next few days or weeks.

• dw to sort out tracking path.

Next Meeting

November 3, 12 noon Eastern

Reference

Indigo Simultaneous Release

Planning Council Members

Simultaneous Release Roles and Simultaneous Release Roles/EMO