Jump to: navigation, search

Difference between revisions of "Planning Council/February 01 2012"

(Issues or Exceptions)
(Other Business)
 
(8 intermediate revisions by the same user not shown)
Line 23: Line 23:
 
| Chris Aniszczyk  
 
| Chris Aniszczyk  
 
| Technology (PMC)  
 
| Technology (PMC)  
|  
+
| Y
 
|-
 
|-
 
| John Arthorne
 
| John Arthorne
 
| Eclipse (PMC)  
 
| Eclipse (PMC)  
|  
+
| Y
 
|-
 
|-
 
| Mik Kersten
 
| Mik Kersten
Line 35: Line 35:
 
| Brian Payton  
 
| Brian Payton  
 
| Datatools (PMC)  
 
| Datatools (PMC)  
|  
+
| Y
 
|-
 
|-
 
| Doug Schaefer
 
| Doug Schaefer
Line 41: Line 41:
 
|  
 
|  
 
|-
 
|-
| Adrian Mos (Marc Dutoo)
+
| Adrian Mos (R.... ?)
 
| SOA (PMC)  
 
| SOA (PMC)  
|
+
| D
 
|-
 
|-
 
| Ed Merks  
 
| Ed Merks  
Line 51: Line 51:
 
| Jesse McConnell
 
| Jesse McConnell
 
| Rt (PMC)  
 
| Rt (PMC)  
|  
+
| Y
 
|-
 
|-
 
| David Williams  
 
| David Williams  
 
| WTP (PMC) (appointed Chair)  
 
| WTP (PMC) (appointed Chair)  
|  
+
| Y
 
|-
 
|-
 
| Gary Xue  
 
| Gary Xue  
Line 79: Line 79:
 
| Neil Hauge  
 
| Neil Hauge  
 
| Oracle (Strategic Developer)  
 
| Oracle (Strategic Developer)  
|  
+
| Y
 
|-
 
|-
 
| Kaloyan Raev  
 
| Kaloyan Raev  
Line 87: Line 87:
 
| Pascal Rapicault  
 
| Pascal Rapicault  
 
| Sonatype (Strategic Developer)  
 
| Sonatype (Strategic Developer)  
|
+
| Y
 
|-
 
|-
 
| Markus Knauer  
 
| Markus Knauer  
 
| Innoopract (Strategic Developer)  
 
| Innoopract (Strategic Developer)  
|  
+
| Y
 
|-
 
|-
 
| Christian Kurzke  
 
| Christian Kurzke  
Line 99: Line 99:
 
| Achim Loerke  
 
| Achim Loerke  
 
| BREDEX (Strategic Developer)  
 
| BREDEX (Strategic Developer)  
|  
+
| Y
 
|-
 
|-
 
| (PMC rep)
 
| (PMC rep)
Line 144: Line 144:
 
:Exceptions for projects not in M4, that still will to join Juno:  
 
: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)
 
:: Virgo approved during 1/05 meeting (from rt PMC list, will be in M6)
:: BPEL approved on mailing list (as in M5?)  
+
:: BPEL approved on mailing list (as late for M4, but in M5)  
 
:: <del>... code recommenders (in by M5, but not in M4?) Did anyone bring them forward for exception? </del>  
 
:: <del>... code recommenders (in by M5, but not in M4?) Did anyone bring them forward for exception? </del>  
 
::: Issue Resolved (good to know some people read agenda :) ... but, is process unclear? ... Chris? :)   
 
::: Issue Resolved (good to know some people read agenda :) ... but, is process unclear? ... Chris? :)   
:: Code Recommenders approved on mailing list (as late for M4, but in my M5).  
+
:: Code Recommenders approved on mailing list (as late for M4, but in M5).  
 
:: Others?
 
:: Others?
  
Line 164: Line 164:
 
* Kepler (EMO has vetted the name ... thanks Chris!)
 
* Kepler (EMO has vetted the name ... thanks Chris!)
 
:: Guess I should announce? Or do you want to Chris? On committers list?
 
:: Guess I should announce? Or do you want to Chris? On committers list?
 +
::: ''Chris agreed to send announcement note to 'committers list'''
  
 
=== Other Business ===  
 
=== Other Business ===  
  
 
* Need discussion and decision on "what is allowed in common info center". Pros? Cons? Alternatives?  See {{bug|369395}}.
 
* Need discussion and decision on "what is allowed in common info center". Pros? Cons? Alternatives?  See {{bug|369395}}.
 +
:: Concern expressed for "extra work" on webmasters part but we can leave to them to throttle that, but no objections to following the "if you run on Indigo, you can be in Indigo Help" (that is, not that confusing if then not in Indigo repo). It was also suggested there might be easier ways to let projects "add their own jars to info center" (reducing workload on webmasters, allowing faster turn around, etc.) ... suggested to open enhancement request in bugzilla if desired, as slightly separate issue.''
  
* Thoughts on "Java Development Tools" category? See {{bug|369258}} [Immediate issue has been resolved, but, not many comments ... so, feel free to comment or open new bugs on "categories"].
+
* Thoughts on "Java Development Tools" category? See {{bug|369258}} [Immediate issue has been resolved, but, not many comments ... so, feel free to comment or open new bugs on "categories"].  
 +
:: ''No particular comment ... might want to change the current label of "Programming Languages" to "Programming Languages and Tools" or something ... but, the idea of having one category for all languages was thought good.''
  
 
* Fair (and desired?) to add "provide non-greedy repository" to requirements? 'Should' or 'must'? See [[SimRel/Simultaneous_Release_Requirements#Provide_optimized_p2_repository_.28partially_tested.29| Provide_optimized_p2_repository section]]. I propose: <br />
 
* Fair (and desired?) to add "provide non-greedy repository" to requirements? 'Should' or 'must'? See [[SimRel/Simultaneous_Release_Requirements#Provide_optimized_p2_repository_.28partially_tested.29| Provide_optimized_p2_repository section]]. I propose: <br />
 
''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 [http://wiki.eclipse.org/Equinox/p2/Publisher p2 Publisher wiki] for some history and details on this issue of greedy vs. non-greedy requirements.''
 
''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 [http://wiki.eclipse.org/Equinox/p2/Publisher 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 [[SimRel/Priorities| project priorities]].  
 
* Project Priorities: Please review and be prepared to discuss this proposed "policy document" about [[SimRel/Priorities| 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.''
  
 
* Still comfortable with "4.2 as primary"?  
 
* Still comfortable with "4.2 as primary"?  
 +
 +
:''Overall, Mike Wilson's note to cross-project list was "comforting", but still some concern that overall, to the general user, it might seem like a step backwards, if they lose function or performance (and, hence, hurt the reputation of Eclipse) ... that is a strong '''if''' they lose function or performance (which is currently not known, just feared). In particular, they might not "see" any benefit to using 4.2 since much of the improvement is in the internal architecture, for the future. [One member, you can guess who :), made an analogy to p2 ... had to push trough a rough patch to end up with a much better solution ... and wondered if 4.2 would be like that?] It was suggested that "messaging" will be very important, to set expectations appropriately. dw TODO: send note to McQ with suggestion that he (and Eclipse PMC) and Ian work on appropriate messaging. ''
  
 
* Anything else?
 
* Anything else?
 +
: {{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.
  
 
== Next Meeting  ==
 
== Next Meeting  ==

Latest revision as of 16:01, 1 February 2012

Logistics

Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, February 01, 2012, at 1200 Eastern
Dial-in: For the call-in numbers, see the "Project Review" number on Foundation Portal page.

Members and Attendees

PMC (and Strategic) Reps
Chris Aniszczyk Technology (PMC) Y
John Arthorne Eclipse (PMC) Y
Mik Kersten Mylyn (ALM) PMC
Brian Payton Datatools (PMC) Y
Doug Schaefer Tools (PMC)
Adrian Mos (R.... ?) SOA (PMC) D
Ed Merks Modeling (PMC)
Jesse McConnell Rt (PMC) Y
David Williams WTP (PMC) (appointed Chair) Y
Gary Xue Birt (PMC)
Wayne Beaton Eclipse Foundation (appointed)
Strategic Reps
Cedric Brun OBEO (Strategic Developer)
Stefan Daume Cloudsmith Inc.(Strategic Developer)
Neil Hauge Oracle (Strategic Developer) Y
Kaloyan Raev SAP AG (Strategic Developer)
Pascal Rapicault Sonatype (Strategic Developer) Y
Markus Knauer Innoopract (Strategic Developer) Y
Christian Kurzke Motorola (Strategic Developer)
Achim Loerke BREDEX (Strategic Developer) Y
(PMC rep) Actuate (Strategic Developer) X
(PMC rep) IBM (Strategic Developer) X
Inactive
[no name] TPTP (PMC) X
[no name] CA Inc. (Strategic Consumer) X

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

Announcements

  • Any?

Indigo SR2

  • Any issues?

Juno

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 (in by M5, but not in M4?) Did anyone bring them forward for exception?
Issue Resolved (good to know some people read agenda :) ... but, is process unclear? ... Chris? :)
Code Recommenders approved on mailing list (as late for M4, but in M5).
Others?
  • Anyone "dropping out" that should be removed from aggregation build?
I know there are potential, possible issues with Riena (not being in common repo, as _might_ not "achieve 4.2". Discussions on-going.
Anyone else? How to compare "participating projects" list with "b3aggrcon" files?

Plans

  • anything to look at? In particular, plans specifying "planned support for 3.8 workbench"?

Juno+1 Name

  • Kepler (EMO has vetted the name ... thanks Chris!)
Guess I should announce? Or do you want to Chris? On committers list?
Chris agreed to send announcement note to 'committers list'

Other Business

  • Need discussion and decision on "what is allowed in common info center". Pros? Cons? Alternatives? See bug 369395.
Concern expressed for "extra work" on webmasters part but we can leave to them to throttle that, but no objections to following the "if you run on Indigo, you can be in Indigo Help" (that is, not that confusing if then not in Indigo repo). It was also suggested there might be easier ways to let projects "add their own jars to info center" (reducing workload on webmasters, allowing faster turn around, etc.) ... suggested to open enhancement request in bugzilla if desired, as slightly separate issue.
  • Thoughts on "Java Development Tools" category? See bug 369258 [Immediate issue has been resolved, but, not many comments ... so, feel free to comment or open new bugs on "categories"].
No particular comment ... might want to change the current label of "Programming Languages" to "Programming Languages and Tools" or something ... but, the idea of having one category for all languages was thought good.

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.
  • Still comfortable with "4.2 as primary"?
Overall, Mike Wilson's note to cross-project list was "comforting", but still some concern that overall, to the general user, it might seem like a step backwards, if they lose function or performance (and, hence, hurt the reputation of Eclipse) ... that is a strong if they lose function or performance (which is currently not known, just feared). In particular, they might not "see" any benefit to using 4.2 since much of the improvement is in the internal architecture, for the future. [One member, you can guess who :), made an analogy to p2 ... had to push trough a rough patch to end up with a much better solution ... and wondered if 4.2 would be like that?] It was suggested that "messaging" will be very important, to set expectations appropriately. dw TODO: send note to McQ with suggestion that he (and Eclipse PMC) and Ian work on appropriate messaging.
  • Anything else?
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.

Next Meeting

  • March 7, 2012 (our regular "first Wednesday" meeting, at Noon Eastern).

Reference

Juno Wiki page
Planning Council/Indigo retrospective
Planning Council Members
Simultaneous Release Roles and Simultaneous Release Roles/EMO