Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Planning Council/March 07 2012"

(Indigo SR2)
(Other Business)
 
(29 intermediate revisions by 2 users 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
 
| Mylyn (ALM) PMC  
 
| Mylyn (ALM) PMC  
|  
+
| Y
 
|-
 
|-
 
| Brian Payton  
 
| Brian Payton  
 
| Datatools (PMC)  
 
| Datatools (PMC)  
|
+
| Y
 
|-
 
|-
 
| Doug Schaefer
 
| Doug Schaefer
 
| Tools (PMC)  
 
| Tools (PMC)  
|  
+
| Y
 
|-
 
|-
 
| Adrian Mos  
 
| Adrian Mos  
Line 51: Line 51:
 
| Jesse McConnell
 
| Jesse McConnell
 
| Rt (PMC)  
 
| Rt (PMC)  
|
+
| Y
 
|-
 
|-
 
| David Williams  
 
| David Williams  
Line 63: Line 63:
 
| Wayne Beaton  
 
| Wayne Beaton  
 
| Eclipse Foundation (appointed)  
 
| Eclipse Foundation (appointed)  
|  
+
| Y
 
|}
 
|}
 
|
 
|
Line 79: Line 79:
 
| Neil Hauge  
 
| Neil Hauge  
 
| Oracle (Strategic Developer)  
 
| Oracle (Strategic Developer)  
|
+
| Y
 
|-
 
|-
 
| Kaloyan Raev  
 
| Kaloyan Raev  
Line 87: Line 87:
 
| Igor Fedorenko
 
| Igor Fedorenko
 
| Sonatype (Strategic Developer)  
 
| Sonatype (Strategic Developer)  
|
+
| Y
 
|-
 
|-
 
| Markus Knauer  
 
| Markus Knauer  
 
| Innoopract (Strategic Developer)  
 
| Innoopract (Strategic Developer)  
|
+
| Y
 
|-
 
|-
 
| Christian Kurzke  
 
| Christian Kurzke  
Line 130: Line 130:
 
== Announcements  ==
 
== Announcements  ==
  
* Any?
+
* Welcome Igor Fedorenko as new Sonatype Strategic Developer Representative.
 +
* Any others?
  
 
== Indigo SR2 ==
 
== Indigo SR2 ==
  
 
* Success? Feedback?  
 
* Success? Feedback?  
* Should our common "release repo" contain only the latest? So at SR1 would save half of initial download time/amount and at SR2 would save 2/3rds of initial time/amount ... And move older stuff to different "site"? The site would be named something like .../releases/juno/permanent or .../releases/juno/complete 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 guess if someone updated, and then wanted to revert, they'd also have to manually add the "complete" URL to their list of sites.  Read the [http://dev.eclipse.org/mhonarc/lists/p2-dev/msg04680.html msg chain on p2-dev list].
+
 
 +
:''None discussed (but, send note to mailing list, etc., if anything occurs to you later''.
 +
 
 +
* 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 stuffPlease read the [http://dev.eclipse.org/mhonarc/lists/p2-dev/msg04680.html 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 strong view to change, so normally status quo would rule. But, we did discuss it is a little hard for us to know magnitude of problem, and if it'd be worth trading off the current function, so, a bug might be worth opening, and see if some "world wide" data was worth collecting. To us, at meeting, there's a big difference if its 90 seconds for most people and the would improve to 30 seconds. Versus 15 minutes for most of world, thus reducing to 5 minutes. Concern was also expressed that it may be an inherent problem/limitation with p2 and this "fix" would be sort of "temporary" ... that if future repos grew to three times current size, we'd be in the same "poor performance" category, unless p2 was improved or some other solution found.''
 +
 
 +
::''ACTION: dw to open cross-project bug to discuss further and provide minor "test case". May clear with webmasters first, since would hate for people to start doing "hundreds of tests" swamping the server even further ... maybe they know of a few key locations they could get to cooperate in a test?''
 +
 
 +
* 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?
 +
 
 +
::''Will leave as "for awareness" until/unless bug open. John did say, "he didn't know about magnitude of the bug, but that he thought is could be done safely, since its just used in UI" ... not a fundamental IU used in builds or installs, or anything. I guess anyone who had made "internal mirrors" might need to redo?''
  
 
== Juno ==
 
== Juno ==
  
 
Ready for M6?
 
Ready for M6?
 +
 +
* Sounds like fair progress towards moving to "non greedy" publishers. 
  
 
=== Issues or Exceptions ===
 
=== Issues or Exceptions ===
  
* Any issues? Everyone in? Any exceptions known?
+
==== Any issues? Everyone in? Any exceptions known? ====
  
 
:Exceptions for projects not in M4, that still will to join Juno:  
 
:Exceptions for projects not in M4, that still will to join Juno:  
Line 149: Line 169:
 
:: BPEL approved on mailing list (as late for M4, but in M5)  
 
:: 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).  
 
:: Code Recommenders approved on mailing list (as late for M4, but in M5).  
:: Koneki project ... joining M6 ... vote pending on mailing list.
+
:: Koneki project approved on mailing list (as late for M5, but joining in M6).  
 
:: Others?
 
:: Others?
  
* Anyone "dropping out" that should be removed from aggregation build?
+
==== Anyone "dropping out" that should be removed from aggregation build? ====
  
:: removed:  
+
:: removed following b3aggrcon files, for M6:  
  
 
:::dsdp-mjt
 
:::dsdp-mjt
Line 163: Line 183:
 
:::stp  
 
:::stp  
  
* What to do about Papyrus (and XWT dependency), both in general ({{bug|370974}}), and specific for this case.
+
==== What to do about Papyrus (and non released 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}}?
 +
:: ''Consensus was "yes"''
 +
: 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?
 +
:: They could also release/join during SR1, etc., if things work out by then.
 +
:: 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.
 +
 
 +
:''Agreement they can't release (much less be apart of train) with unreleased dependencies. Wayne said there could maybe be exceptions, but it would have to be a very special case, under just the right conditions. Also, it was said, that given that "it was done wrong last year" speaks to the magnitude of their problem ... that is, that it is still not fixed/released by now, is even more reason to not allow it to happen again.''
 +
 
 +
:''ACTION: dw to send note to papyrus and modeling pmc saying "no", and remove them from aggregation build, unless they know something we don't (e.g. I'm pretty sure XWT is central to their function, but for all I know maybe they could just leave it out, and haven't said so yet.''
 +
 
 +
: Does anyone suspect any other, similar cases?
 +
 
 +
:''None mentioned.''
  
 
=== Plans ===  
 
=== Plans ===  
  
 
* anything to look at? In particular, plans specifying "planned support for 3.8 workbench"?
 
* anything to look at? In particular, plans specifying "planned support for 3.8 workbench"?
 +
 +
:''no consolidated report yet''
 +
 +
* Is there a controversy brewing over what is released in EPP and how to decide? See [http://dev.eclipse.org/mhonarc/lists/cbi-dev/msg00133.html chain of msgs on cbi-dev list].
 +
::* The proposal (to summarize, assuming no communication problems) was for the "bits" in Eclipse Classic, and the Juno repository to be provided by the Eclipse releng team.
 +
::: But, that the bits used in EPP (for the platform/SDK bundles) come from the CBI builds, and the rest come from common repository.
 +
:::* Issue one: this means there would be two versions of platform bundles "in the wild" for the Juno release.
 +
:::: Either with same version and qualifiers, but (probably slightly different content), or different qualifiers but maybe same content ... either case leading to chaos (IMHO).
 +
:::: I think "updates" and "what would adopter's customer's end up with" are huge problems for Eclipse, in these cases.
 +
:::* Issue two, while is is true, Eclipse is open source, and "people can do with it what they want", I think it is entirely up to the EPP project what they do and how they do it (not "CBI") and such a large technical/process change should get plenty of discussion with EPP Project (and, probably their PMC ... is this something they think is a good idea?)
 +
:::* Issue three, it seems all this is happening "last minute" instead of the proven "Eclipse way" of producing milestones, making steady, incremental progress towards a release.
 +
:::* Issue four, would projects still want to be in EPP, if they knew bits would be different than if they "built their own"?
 +
:::* Issue five, I think the Planning Council is in charge of "the release plan" (since, it effects all top-level projects and PMCs and Strategic Members) so I think we are obligated to make a statement on this issue.
 +
 +
::* If not obvious, I think we all want to be supportive of CBI and the LTS efforts, but ... even if bundles are planned/considered to be identical, then why have two versions of them? Part of the answer is to make very rapid progress in CBI and LTS. Again ... I think we all support that rapid progress, but I'd prefer a plan that had same bits, all around. Perhaps SR1?
 +
 +
::* Any thoughts? Suggestions for what our Planning Council statement should be? Can we make a concrete statement or recommendation?
 +
 +
::''Thanks to Andrew Ross for joining the call as a"special guest" to answer questions and hear concerns and learn more about bundles and our normal way of ordinating a release.''
 +
 +
::''Agreement that having "two versions" of bundles for one release is not tenable (for maintenance, predictable builds, updates, etc.) and would tarnish Eclipse's reputation for producing reliable, predictable releases. In some ways, it was speculated, that maybe the proposal made on cbi-dev list was just a case of partial mis-communication or terminology issues of not  understanding the nuances of repositories, installs, updates, adopter scenarios, as well as the Eclipse dev. process and the project decision processes.''
 +
 +
::''Markus did say he might be willing to try using CBI output in some "test builds" for evaluation, if anyone thought that would be useful, but would not want to "release" those, if the platform released something different in the common repository. The EPP packages all come from the "common repository" which he does not want to change -- that is a key part of the "coordinated" and "update" story at Eclipse. And, it is up to each project to decide what goes into that common repository (that is, they decide what they contribute), since it is their responsibility. And, the Platform team has decided that they will contribute the bits from the PDE build for SR0 in June ... but they are willing to consider changing build systems after June, if CBI proves ready by then, or even after SR1 (for SR2 release) if CBI not ready by September or not enough time to evaluate it by September.''
 +
 +
::''The Planning Council agreed it would be a better plan to work "bottom up", to first prove the CBI can build the same thing as the platform build, and to then move the platform to a CBI build, and then end up with one set of bundles per release. It was felt that this might be feasible by SR1. Even that would be aggressive, and have some risk of "making it on time" (without sacrificing quality of the builds produced) but would feasibly allow at least some time to iterate and investigate and prove that it was adequate if not identical, before committing bundles "out in to the wild". Perhaps for Juno, "LTS" could "start with" SR2 ... though long term, Andrew told us, LTS members do want to be able to have their own builds/fixes/streams even immediately after SR0, if they so desired.''
 +
 +
::''So, our recommendation is for CBI and LTS interests to come up with a plan to get the platform to move to CBI build by SR1 or SR2, and not plan to release two sets of bundles, as well as work with the EPP project to make sure the project (and the package maintainers and committers) agree with any proposals made to change the way things are done with EPP builds or packages.''
 +
 +
::''Planning Council members (or, members of their teams) can support the CBI and LTS efforts by at least opening bugs/feature requests on what's needed for CBI to "work for them" (in cbi bugzilla product), be explicit about acceptance criteria, as well as contribute man power to try the builds, test the results, etc., if not actually provide tools for CBI (the Common Build Infrastructure).''
 +
 +
::''ACTION: dw will post "recommendation" to CBI dev list for proper visibility''.
  
 
=== Other Business ===  
 
=== Other Business ===  
  
* 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 />
+
* I added some info about p2.mirrorsURL and p2.index to [[SimRel/Simultaneous_Release_Requirements#Provide_optimized_p2_repository_.28partially_tested.29| 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.  
''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.''
+
:''no complaints''
  
 
* 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''
+
: One issue: should we mention LTS? Technically ... it is not in our mission or scope.  
:: ''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".''
+
: Are we in agreement these can be published a "priorities from Planning Council's point of view" to begin "socializing" the idea?
:: ''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.''
+
  
 +
: ''Good discussion. Suggestion to add point about security issues getting high priority (though, not typically not even part of "simultaneious release" priorities, per se). Agreement to still mention LTS priorities but to move it so it does not appear Planning Council is trying to govern LTS. ''
  
:: {{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.
+
: ''ACTION: dw to send note to cross project list to begin socializing the ideas of documenting priorities ... but, emphasize, no change in procedures or requirements, just trying to better document what we do.
 +
 
 +
* Will Java pack200 issue {{bug|361628}} in equinox 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.
 +
 
 +
: ''Jesse did not know, had not come up on rt-pmc call ... but, I'm sure we'll hear about it, if change to procedures about nested jars become recommended.''
  
 
* Anything else?
 
* Anything else?
 +
 +
: ''Nothing mentioned ... but ... did run out of time ... so feel free to mention issues on mailing list or bring to EclipseCon meeting in a few weeks.''
  
 
== Next Meeting  ==
 
== Next Meeting  ==
  
 
* EclipseCon face-to-face meeting: Sunday, March 24, 2 - 4 local time (Eastern). Joint meeting with Arch. Council 4 - 5.  
 
* 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).
 
* April 4, 2012 (our regular "first Wednesday" meeting, at Noon Eastern).

Latest revision as of 22:54, 7 March 2012

Logistics

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

PMC (and Strategic) Reps
Chris Aniszczyk Technology (PMC) Y
John Arthorne Eclipse (PMC) Y
Mik Kersten Mylyn (ALM) PMC Y
Brian Payton Datatools (PMC) Y
Doug Schaefer Tools (PMC) Y
Adrian Mos SOA (PMC)
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) Y
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)
Igor Fedorenko Sonatype (Strategic Developer) Y
Markus Knauer Innoopract (Strategic Developer) Y
Christian Kurzke Motorola (Strategic Developer)
Achim Loerke BREDEX (Strategic Developer)
(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

  • Welcome Igor Fedorenko as new Sonatype Strategic Developer Representative.
  • Any others?

Indigo SR2

  • Success? Feedback?
None discussed (but, send note to mailing list, etc., if anything occurs to you later.
  • 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 strong view to change, so normally status quo would rule. But, we did discuss it is a little hard for us to know magnitude of problem, and if it'd be worth trading off the current function, so, a bug might be worth opening, and see if some "world wide" data was worth collecting. To us, at meeting, there's a big difference if its 90 seconds for most people and the would improve to 30 seconds. Versus 15 minutes for most of world, thus reducing to 5 minutes. Concern was also expressed that it may be an inherent problem/limitation with p2 and this "fix" would be sort of "temporary" ... that if future repos grew to three times current size, we'd be in the same "poor performance" category, unless p2 was improved or some other solution found.
ACTION: dw to open cross-project bug to discuss further and provide minor "test case". May clear with webmasters first, since would hate for people to start doing "hundreds of tests" swamping the server even further ... maybe they know of a few key locations they could get to cooperate in a test?
  • 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?
Will leave as "for awareness" until/unless bug open. John did say, "he didn't know about magnitude of the bug, but that he thought is could be done safely, since its just used in UI" ... not a fundamental IU used in builds or installs, or anything. I guess anyone who had made "internal mirrors" might need to redo?

Juno

Ready for M6?

  • Sounds like fair progress towards moving to "non greedy" publishers.

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).
Others?

Anyone "dropping out" that should be removed from aggregation build?

removed following b3aggrcon files, for M6:
dsdp-mjt
emf-teneo
emf-mint
m2t-jet
tools-sequoyah
stp

What to do about Papyrus (and non released 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?
Consensus was "yes"
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?
They could also release/join during SR1, etc., if things work out by then.
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.
Agreement they can't release (much less be apart of train) with unreleased dependencies. Wayne said there could maybe be exceptions, but it would have to be a very special case, under just the right conditions. Also, it was said, that given that "it was done wrong last year" speaks to the magnitude of their problem ... that is, that it is still not fixed/released by now, is even more reason to not allow it to happen again.
ACTION: dw to send note to papyrus and modeling pmc saying "no", and remove them from aggregation build, unless they know something we don't (e.g. I'm pretty sure XWT is central to their function, but for all I know maybe they could just leave it out, and haven't said so yet.
Does anyone suspect any other, similar cases?
None mentioned.

Plans

  • anything to look at? In particular, plans specifying "planned support for 3.8 workbench"?
no consolidated report yet
  • The proposal (to summarize, assuming no communication problems) was for the "bits" in Eclipse Classic, and the Juno repository to be provided by the Eclipse releng team.
But, that the bits used in EPP (for the platform/SDK bundles) come from the CBI builds, and the rest come from common repository.
  • Issue one: this means there would be two versions of platform bundles "in the wild" for the Juno release.
Either with same version and qualifiers, but (probably slightly different content), or different qualifiers but maybe same content ... either case leading to chaos (IMHO).
I think "updates" and "what would adopter's customer's end up with" are huge problems for Eclipse, in these cases.
  • Issue two, while is is true, Eclipse is open source, and "people can do with it what they want", I think it is entirely up to the EPP project what they do and how they do it (not "CBI") and such a large technical/process change should get plenty of discussion with EPP Project (and, probably their PMC ... is this something they think is a good idea?)
  • Issue three, it seems all this is happening "last minute" instead of the proven "Eclipse way" of producing milestones, making steady, incremental progress towards a release.
  • Issue four, would projects still want to be in EPP, if they knew bits would be different than if they "built their own"?
  • Issue five, I think the Planning Council is in charge of "the release plan" (since, it effects all top-level projects and PMCs and Strategic Members) so I think we are obligated to make a statement on this issue.
  • If not obvious, I think we all want to be supportive of CBI and the LTS efforts, but ... even if bundles are planned/considered to be identical, then why have two versions of them? Part of the answer is to make very rapid progress in CBI and LTS. Again ... I think we all support that rapid progress, but I'd prefer a plan that had same bits, all around. Perhaps SR1?
  • Any thoughts? Suggestions for what our Planning Council statement should be? Can we make a concrete statement or recommendation?
Thanks to Andrew Ross for joining the call as a"special guest" to answer questions and hear concerns and learn more about bundles and our normal way of ordinating a release.
Agreement that having "two versions" of bundles for one release is not tenable (for maintenance, predictable builds, updates, etc.) and would tarnish Eclipse's reputation for producing reliable, predictable releases. In some ways, it was speculated, that maybe the proposal made on cbi-dev list was just a case of partial mis-communication or terminology issues of not understanding the nuances of repositories, installs, updates, adopter scenarios, as well as the Eclipse dev. process and the project decision processes.
Markus did say he might be willing to try using CBI output in some "test builds" for evaluation, if anyone thought that would be useful, but would not want to "release" those, if the platform released something different in the common repository. The EPP packages all come from the "common repository" which he does not want to change -- that is a key part of the "coordinated" and "update" story at Eclipse. And, it is up to each project to decide what goes into that common repository (that is, they decide what they contribute), since it is their responsibility. And, the Platform team has decided that they will contribute the bits from the PDE build for SR0 in June ... but they are willing to consider changing build systems after June, if CBI proves ready by then, or even after SR1 (for SR2 release) if CBI not ready by September or not enough time to evaluate it by September.
The Planning Council agreed it would be a better plan to work "bottom up", to first prove the CBI can build the same thing as the platform build, and to then move the platform to a CBI build, and then end up with one set of bundles per release. It was felt that this might be feasible by SR1. Even that would be aggressive, and have some risk of "making it on time" (without sacrificing quality of the builds produced) but would feasibly allow at least some time to iterate and investigate and prove that it was adequate if not identical, before committing bundles "out in to the wild". Perhaps for Juno, "LTS" could "start with" SR2 ... though long term, Andrew told us, LTS members do want to be able to have their own builds/fixes/streams even immediately after SR0, if they so desired.
So, our recommendation is for CBI and LTS interests to come up with a plan to get the platform to move to CBI build by SR1 or SR2, and not plan to release two sets of bundles, as well as work with the EPP project to make sure the project (and the package maintainers and committers) agree with any proposals made to change the way things are done with EPP builds or packages.
Planning Council members (or, members of their teams) can support the CBI and LTS efforts by at least opening bugs/feature requests on what's needed for CBI to "work for them" (in cbi bugzilla product), be explicit about acceptance criteria, as well as contribute man power to try the builds, test the results, etc., if not actually provide tools for CBI (the Common Build Infrastructure).
ACTION: dw will post "recommendation" to CBI dev list for proper visibility.

Other Business

no complaints
  • 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?
Good discussion. Suggestion to add point about security issues getting high priority (though, not typically not even part of "simultaneious release" priorities, per se). Agreement to still mention LTS priorities but to move it so it does not appear Planning Council is trying to govern LTS.
ACTION: dw to send note to cross project list to begin socializing the ideas of documenting priorities ... but, emphasize, no change in procedures or requirements, just trying to better document what we do.
  • Will Java pack200 issue bug 361628 in equinox 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.
Jesse did not know, had not come up on rt-pmc call ... but, I'm sure we'll hear about it, if change to procedures about nested jars become recommended.
  • Anything else?
Nothing mentioned ... but ... did run out of time ... so feel free to mention issues on mailing list or bring to EclipseCon meeting in a few weeks.

Next Meeting

  • 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).

Reference

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

Copyright © Eclipse Foundation, Inc. All Rights Reserved.