Planning Council/October 05 2011
Contents
Logistics
| Meeting Title: | Planning Council Conference Call |
| Date & Time: | Wednesday, October 05, 2011, at 1200 Eastern |
| Dial-in: | For the call-in numbers, see the "Project Review" number on Foundation Portal page. |
Members and Attendees
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Note: "Inactive" refers to Strategic Members we have not heard from in a year or so, and have been unable to convince to participate. Those members can become active again at any time. Contact David Williams if questions.
Note: feel free to correct any errors/omissions in above attendance record.
Y = Yes, attended
N = No, did not
R = regrets sent ahead of time
X = not expected
Announcements
- Any? none
Indigo SR2
- Anything? none
Juno Plan and Requirements
Plan
I've updated our Planning Document with SR dates ... I consider the document "done for Juno" ... except for links (and content) for requirements and tracking. (That is, please proof read, especially dates for SRs).
Requirements
Previous year's document on "eclipse web", moved to "eclipse wiki". I have edited, for clarity and organization. Only "requirement" I've changed, so far, it the one about 3.8 support (previously, was about 4.1 support).
In general, everyone thought "fine", but admitted had not had time to read carefully yet, so (I hope) still room for improvements to be made.
issue: is there a way to make clearer what is "normal Eclipse Foundation requirement" and what is "release train" requirement. I think it pretty obvious, if someone reads whole document, but TODO: will look at changing/adding to the 3 main headings to make clearer.
issue: is the "using Orbit bundles" an Eclipse Foundation requirement or train requirement? Answer: train. EF requires the CQ, but does not specify where to get it from. In general, should be easier for projects to get from Orbit, and avoids "inconsistent" bundles if things installed together in unexpected ways, whether on train, or not. So it would be odd _not_ to get from Orbit, even for non-train release. There might be some exceptions for some projects (such as Virgo?) where "they have existing customers that expect the bundle to be in a certain form" ... similar to any "software migration" when existing customers exist, I guess. In theory, such exceptions should be "equally valid" whether on train, or not ... but there could be real "conflicts" that would preclude being in common repo.
issue: is the "must be signed" requirement from Eclipse Foundation or release train? Answer: train. Wayne clarified, if "signed or not" is release train requirement, but Eclipse Foundation requires "if it is signed, and distributed from Eclipse, it must be signed by the Eclipse certificate".
Other requirements?
none mentioned.
Other clarifications?
none mentioned. But members will raise issues on planning council mailing list, or on "talk page" of wiki. (typos and small grammar fixes can just be made on wiki, directly, by any PC member). All PMC members are encouraged to "watch" that wiki page, to be aware of changes or discussions.
Checklist (aka tracker)
Is it worth someone investing the time to update this?
I have heard both ways, some like, some don't ... so I hope others have some strong opinions one way or the other?
Let's first decide what we want ... then we can discuss how to get it done, if desired.
In general, thought to be fairly worth while, and fairly easy for committers to fill out ... as long as no one "hounded" to do it. In particular the "checklist" aspect was thought nice, in that helped guide people, so especially useful to new projects. Especially important to adopters/consumers to learn more about a project, such as "is it tested for accessibility" (which some adopters need to know, for selling services/products in some markets). Some of the "difficulty" to projects is in the inaccuracies ... such as something reported as "not complete yet" and people just have to fill in "junk URL" to get the form happy. And, is easy in that many/much data does not change year to year ... such as a link to milestone documents, or similar. Another way to help "automate" some information is to provide links to the "report pages" where things like "signed or not" and "4 part version numbers" can be tested, instead of merely checked off as "done or not done". TODO: for now, will mark which requirements have reports and provide a link to main report page in requirements document. Unlikely this could ever be "fully automated, project by project" (without a lot of effort).
Was mentioned that "resource constraints" to improve the "Portal tracker" is a real constraint. As an aside, Wayne mentioned Portal may be "completely replaced" perhaps second quarter of 2012 (so, may need some action at that time: port code to new tracker? Move tracker out of Portal? Achim mentioned he (they) might be interested in helping to support/improve that tracking code, so he will discuss "internally" and chat with Wayne about it before next meeting. (There is, some "portal code" that no one but EF could access ... but some of it is "just" PHP pages that others could provide patches for.)
Next Meeting
-
November 2, 2011 (our regular "first Wednesday" meeting, at Noon Eastern).- (Achim) This is the first day of EclipseCon Europe (clashing with the 10 Years Eclipse keynote and the 10th Birthday party)!
- Reschedule 11/2 meeting to November 9, 2011, at Noon (Eastern)?
agreed, next meeting 11/9
- Subsequent, December meeting (back to 'first Wednesday'): December 7, 2011, at Noon (Eastern)