Difference between revisions of "Planning Council/March 07 2012"
|Line 130:||Line 130:|
== Announcements ==
== Announcements ==
* Any ?
== Indigo SR2 ==
== Indigo SR2 ==
Revision as of 09:07, 7 March 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
- Welcome Igor as new Sonatype Strategic Developer Representative.
- Any others?
- Success? Feedback?
- Issue to discuss and decide if we need a plan of action: p2 content metadata at SR2 is 3 times what it is at SR0.
- Should our common "release repo" contain only the latest code? And "move" older stuff to different site? The different site would be named something like .../releases/juno/complete or or something, and be simply a different composite (no duplication of actual artifacts). This site would not be "built in" to any update repo lists, but could be used by builds or others that needed "the old stuff". I think if someone updated, and then wanted to revert or rollback the change, they might also have to manually add the ".../releases/juno/complete" URL to their list of sites (assuming p2 GC had cleaned off the old stuff. Please read the msg chain on p2-dev list. There is a trade off of function and performance and want to be sure everyone is aware of it and if anyone has any opinions on if we currently have the right choice.
- Another solution might be to aggregate new stuff, with old, which would have added advantage of making sure all was compatible ... but, a) not sure it would be much smaller and b) requires all projects to do an "expert job" of versioning.
- No bug yet, but I've gotten some email one might be open to "remove categories" from Indigo SR0 and SR1 repositories, to "complete" the fix for the problem caused by linuxtools changing feature IDs in SR2 (See bug 371302). As is, 6 features show up in "Linux tools" category, but 3 are for SR1 and 3 are for SR2 and they can not be all installed (all at once, that is, as most users would "pick them all" if they wanted Linux tools). While not exactly a blocking bug ... is it something that will last for years to come ... not to mention, I wonder if we should always only have one categorization for common repo? (discussed some in bug 314165.
- Any issues/thoughts on this? Allowable? Desirable? Not?
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 approved on mailing list (as late for M5, but joining in M6).
- Anyone "dropping out" that should be removed from aggregation build?
- removed following b3aggrcon files, for M6:
- What to do about Papyrus (and XWT dependency), both in general (bug 370974), and specific for this case.
- In general, can I say the Planning Council agrees with my summary conclusion in the bug 370974#c12?
- Specifically, does the Planning Council agree this means Papyrus can not be in Sim Release? In fact, could not release at all, until this XWT issue is resolved.
- They perhaps could use an "old" version of XWT? But, my guess is that very old release (which happened sort of erroneously) does not have about.html files, etc.
- XWT could graduate/move to its own project and release from there ... but not much time left, and seems unlikely?
- Keep in mind, one bad aspect of this is that Papyrus and some "unreleased" XWT bundles were in Indigo. We should have "caught the error" back then.
- Does anyone suspect any other, similar cases?
- anything to look at? In particular, plans specifying "planned support for 3.8 workbench"?
- Is there a controversy brewing over what is released in EPP and how to decide? See chain of msgs on cbi-dev list.
- I added some info about p2.mirrorsURL and p2.index to Provide_optimized_p2_repository section. I did this to help educate everyone, but, if anyone thinks I've added too much, please let me know.
- Project Priorities: Please review and be prepared to discuss this proposed "policy document" about project priorities.
- One issue: should we mention LTS? Technically ... it is not in our mission or scope.
- Are we in agreement these can be published a "priorities from Planning Council's point of view" to begin "socializing" the idea?
- Will Java pack200 issue bug 361628 need action? Is a fix possible? It will not literally be a problem if everyone published both jar.pack.gz files and jars, but would be inefficient (ending up with "failures" with pack.gz files, and then downloading jars if using Java 7). Keep in mind, we have decided in the past that we should always publish both *.jar and *.jar.pack.gz files ... so, no change in policy for Sim. Release.
- Anything else?
- EclipseCon face-to-face meeting: Sunday, March 24, 2 - 4 local time (Eastern). Joint meeting with Arch. Council 4 - 5.
- Agenda will be developed soon, but good time to discuss Kepler and other "big picture" items.
- April 4, 2012 (our regular "first Wednesday" meeting, at Noon Eastern).