Planning Council/March 07 2012
|Meeting Title:||Planning Council Conference Call|
|Date & Time:||Wednesday, March 07, 2012, 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 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
- Success? Feedback?
- Should our common "release repo" contain only the latest? And move older stuff to different "site"? Read the msg chain on p2-dev list.
Ready 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 ... joining M6 ... vote pending on mailing list.
- Anyone "dropping out" that should be removed from aggregation build?
- What to do about Papyrus (and XWT dependency), both in general (bug 370974), and specific for this case.
- anything to look at? In particular, plans specifying "planned support for 3.8 workbench"?
- Fair (and desired?) to add "provide non-greedy repository" to requirements? 'Should' or 'must'? See Provide_optimized_p2_repository section. I propose:
Clarification on 01/23/2012: the repositories produced and contributed (for Juno and subsequent releases) must use p2 publishers that use greedy='false' by default. See bug 247099 and the p2 Publisher wiki for some history and details on this issue of greedy vs. non-greedy requirements.
- It was affirmed this is important and ok to add to "must do" requirements. If, for some reason, a project can not, they can always file for an exception and we can assess impact then.
- Project Priorities: Please review and be prepared to discuss this proposed "policy document" about project priorities.
- Good discussion
- Somme concern about "E" [now "F", after edits] ... might be some merit to it, but should be reworded to emphasize "abnormally high" amount of CQs, not simply "number of".
- Suggested to mention LTS, as we do EPP.
- Some tangential discussion to get more detailed about ... such as, are there ways still to simplify the process? Such as for "minor" updates to a package. Will continue at next meeting.
- Is was suggested a "flow chart" was needed (like the IP process?) but a) I think that was made in jest, and b) think it will be "next year" before we could formalize into a heuristic.
- Will discus more at March meeting, before considering the document "reviewed and approved" by Planning Council.
- No overall objection to having PC state priorities, but some concern that a lot depends on the context in which the priorities were needed or used. Perhaps add a note these are priorities for producing a timely, predictable release train for adopters, products, and projects, and not that related to "importance" of a project, which could depend on factors such as innovation, demand, and others.
- bug 361628 Not known yet, but some solution is likely needed, and that might require a "mass change" to not "packing" (and not signing?) nested jars.
- Anything else?
- EclipseCon face-to-face meeting: Sunday, March 24, 2 - 4 local time (Eastern). Joint meeting with Arch. Council 4 - 5.
- April 4, 2012 (our regular "first Wednesday" meeting, at Noon Eastern).