Difference between revisions of "Planning Council/March 25 2012"
(→Long Term Planning discussion)
|Line 131:||Line 131:|
== Juno ==
== Juno ==
Revision as of 22:58, 24 March 2012
|Meeting Title:||Planning Council Conference Call|
|Date & Time:||Wednesday, March 25, 2012, at 1400 Eastern|
|Face-to-Face. No Dial-in.||Room: Fairfax B. Second floor of Hyatt.|
Members and Attendees
Note: "Inactive" refers to Strategic Members or PMCs we have not heard from for a while, 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
D = delegated
X = not expected
- How did we do for M6?
Issues or Exceptions
Any issues? Everyone in? Any exceptions known?
- Exceptions for projects not in M4, that still will to join Juno:
- Virgo approved during 1/05 meeting (from rt PMC list, will be in M6)
- BPEL approved on mailing list (as late for M4, but in M5)
- Code Recommenders approved on mailing list (as late for M4, but in M5).
- Koneki project approved on mailing list (as late for M5, but joining in M6).
- Any discussion of Papyrus and XWT situation?
- anything to look at? In particular, plans specifying "planned support for 3.8 workbench"?
- must be a "report" by now? (Wayne?)
- Issues and direction:
Long Term Planning discussion
EclipseCon face-to-face is good time to discuss high level or long term issues. The following items are potential items to discuss ... please add any of your own. They can range from a thought or question, to a specific proposal. The purpose of this part of the meeting is not necessarily to decide or resolve any specific issues (there likely would not be time) but to make sure we are all, as a council, in agreement on our general course, what are most important issues to address, etc.
- Review our Mission and recent retrospectives. In addition to the formal, documented mission, several other motivations tend to influence our efforts:
- improve quality and consistency of Eclipse as a whole,
- make things as easy as possible for committers (while meeting other goals),
- improve "value" of Eclipse, by improving what adopters can adopt and providing what strategic members need.
- Others ...?
- How are we doing? Beside 'being on time' are we achieving the right quality? By helping projects focus on "minimum set" of items that are important for Eclipse as a whole?
- Should we have "must do" items at all? Or, are they just recommendations?
- Are the requirements about right? Too many? Too few?
- Should we have requirement related to bug fix rate? Backlog reduction? unit test coverage?
- How's the aggregation process? Would it be fair to ask for zipped p2 repositories for aggregation input?
- Is the release tracking checklist on Portal worthwhile?
- How's the "new portal" coming? (Wayne)
- Who is the audience(s)? (Projects, PMCs, Planning Council, Adopters).
- Is yearly release (with two service releases) the right interval? Should maintenance be quarterly? Should releases be every other year? Or, perhaps, every other year be a LTS releases with "off" year having less maintenance emphasis?
- Is there too much "pressure" or emphasis that everyone should be part of Simultaneous Release? Or, should it be one of our goals, that every project should be part of the Simultaneous Release? How would we describe or define who should, or who shouldn't?
- What is relationship of Planning Council/Yearly Release and LTS? Conceptually? Governance? Bylaws?
- April 4, 2012 (our regular "first Wednesday" meeting, at Noon Eastern).