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 "Eclipse/PMC"

 
(943 intermediate revisions by 16 users not shown)
Line 1: Line 1:
 +
= Documents =
 +
Some documents written and/or used by the PMC:
 +
 +
* [[E4/Graduation_4.0]]
 +
* [[Eclipse/PMC/Unix Groups]]
 +
 
= Meeting Schedule =
 
= Meeting Schedule =
  
The [http://www.eclipse.org/eclipse/team-leaders.php Eclipse Project PMC] has a weekly phone meeting '''every wednesday at 10.30am EST'''.
+
The [http://www.eclipse.org/eclipse/team-leaders.php Eclipse Project PMC] has a weekly phone meeting '''every Tuesday at 11.00am EST'''.
  
 
= Meeting Minutes =
 
= Meeting Minutes =
'''May 27:''' - McQ, Martin, Steve
 
* {{bug|277735}} releng.tools copyright tool - Martin would like to see it released. Discuss in Arch call.
 
 
<hr/>
 
'''May 20:''' - McQ, Martin
 
* PC Lead: John A suggested to represent Eclipse
 
* Linux: New Launchers built, didn't start on Linux ... I-build was broken, want to know why
 
 
<hr/>
 
'''May 13:''' - McQ, Martin, Jeff, Steve, Philippe
 
* {{bug|273660}} Common Navigator: Pipelining issues with JDT + CDT
 
 
<hr/>
 
'''May 6:''' - McQ, Martin, Jeff
 
* McQ PDE Feature Request
 
** New Target Platform came in late
 
** PMC agrees with trying to fix this, but want to see the final patch before +1
 
* McQ Testplan
 
** People going to test their own because test plan is too complex
 
* Jeff Splash Screen
 
 
 
<hr/>
 
'''Apr 29:''' - McQ, Martin, Steve
 
* Martin: Java6 ref platform - anything between 6u3 and 6u10 (exclusive) was broken, anything after 6u10 (inclusive) has license issues in [http://java.sun.com/javase/6/javase-6-thirdpartyreadme.txt thirdpartylicensereadme.txt].
 
** Suggestion: Dont update the plan document yet, but start running tests with 6u13 on Linux. '''AI McQ''' talk to Kim about this.
 
** '''AI Martin''' make a final attempt to get more info out of Sun.
 
* Steve: Solaris x86 - looks good but some problems with X server
 
* McQ: API Deprecation Policy {{bug|261544}} - '''AI McQ''' synthesise some summary and comment on the bug
 
* M7: Testers found some interesting prolbems with launching Eclipse from Eclipse (depending on VM, BIDI chars in paths dont work)
 
 
 
<hr/>
 
'''Apr 22:''' - McQ, Martin, Steve, Philippe
 
* Steve: Solaris x86 - got a Browser running, looking good,
 
* Steve: Cocoa Sheets - new API - Dialogs associated with a Window: Dialog slides down from title bar
 
** Clients need to opt in through new API because they need to specify a dialog as being adequate for sheet support
 
* Martin: Maintenance builds post SR2
 
** experience in the past has shown only very few, surgically isolated patches so the problem is probably smaller than anticipated
 
** don't want anything produced to appear official -- anything that appears official MUST result in a test pass and this must be avoided
 
** it makes sense to talk about this in the context of "Release Train" and not only "Eclipse Platform" -- Martin filed {{bug|273262}} against the AC
 
* Martin has some update on Sun Java 6 -- will update {{bug|261724}}
 
 
 
<hr/>
 
'''Apr 15:''' - McQ, Jeff, Martin, Steve
 
* McQ: '''Solaris x86''' - OK if we get the machine up and running until Friday, too late for swapping reference platform otherways
 
* '''Polish List''' [[Polish3.5]] - Some developers don't have time for polish items. For now, it's just a list such that we *know* what's coming up.
 
** Martin wondering why we need a separate wiki page, bugzilla query should be enough?
 
** Who owns the Polish list - Eclipse Project Committers. We capture items that we find "stupid" when using Eclipse ourselves.
 
* '''Maintenance builds after 3.4'''
 
** IBM will never consume any community builds: want the absolute minimum of required fixes
 
** If a fix shows up in any IBM product, then it is on a bug somewhere
 
** But fixes are never cumulative
 
** Martin thinks that a first step would be well-defined markup of such "released-to-product" fixes.
 
** Another next step is allowing Eclipse builds by the Community -- we can do anything that's not making Kim's life harder.
 
** How to proceed with communications: open bugs, bugzilla discussions.
 
 
 
<hr/>
 
'''Apr 1:''' - McQ, Jeff, Martin, Steve, Philippe
 
* McQ: Solaris x86 (recommend building since Sun helped at Eclipsecon), Perf results (not trustworthy on Windows?)
 
* Martin: M-builds beyond 3.4.2
 
** Two problems: (a) provide a build system that the community can use, and (b) provide a platform for accumulating fixes easily without risking version collisions etc
 
*** The risk of (b) is high that as a result we'd have some low-quality sea of incompatible fixes. We better don't go with this.
 
** Other solution is allow to cherry-pick on source level - just provide a new target milestone in bugzilla, product builders cherry-pick patches they want to apply and do so locally.
 
* Jeff: OSGi tooling; future plans around build
 
** We need to run builds ourselves (see also above) - e.g. equinox sdk feature is in some internal repository
 
** PDE build has stretched pretty far over time.. what to do with it
 
*** Needs to be one of the main plan items for 3.6, but don't want to wait that long
 
*** SAP perhaps to help out with staffing
 
* Boris to host the arch call since Steve, McQ, Philippe all cannot join
 
 
 
<hr/>
 
'''Mar 18:''' - McQ, Steve, Martin
 
* no arch next week due to EclipseCon
 
* McQ found a performance test that is 8000% slower
 
** teams are overwhelmed (but remind them to check performance tests)
 
* Martin reminded us about use of [http://dev.eclipse.org/mhonarc/lists/eclipse.org-committers/msg00575.html Parallel IP for Mature Projects] and JSch-0.1.41
 
** need to identify uses on the download links (or also inside the downloads?)
 
** EMO has not developed the policy yet
 
** McQ: "Q: Should we just not use the mechanism?"
 
** Downstream consumers may need to test against new lib features early. Just for test and experimentation, not for consumption: want parallel IP in I-builds
 
** McQ: Milestones are a corner case -- some consumers use these in products!
 
** Parallel IP is a tool for projects who want it. A clear policy is one thing. Guidelines for projects to adopt it or not is another thing -- may depend on the number and kind of consumers.
 
** Result: Martin to Bring up that topic on the [[Architecture Council/Meetings/March 22 F2F EclipseCon 2009]],
 
*** Example issues: can't put it in for I-build and remove for Milestone S-build
 
 
<hr />
 
 
'''Mar 11:''' - McQ, Steve, Jeff, Martin
 
* Martin - '''{{bug|227055}} and late API additions'''
 
** McQ: after m6 is too late if it has any downstream impact (changing behavior, deleting things, ...). Plain API additions may slip a week.
 
** Steve: If new API has effect on performance and polish, may look more favorably.
 
** If going in after M6, it needs to go through the process (e-mail and public discussion on eclipse-pmc list).
 
** Strict API Tooling checks to be enabled next week
 
* McQ - '''state of M6'''; some late UI things to review
 
** Some low-risk polish Cocoa items for Eclipsecon (enablers)
 
** Still changes in p2 (after m6), but stabilizing
 
* Martin/Jeff - '''New Target Platform Page''' may require more tweaking - risk of breaking community workflows!
 
** E.g. adding a directory to the target platform; Jeff uses target platforms a lot, so he's likely more exposed than most of the Community... 10 to 15 locations with hundreds of bundles...
 
** Related to the {{bug|224145}} p2 "extension location" problem which broke user workflows. Don't want to have such breakage again.
 
* Jeff - '''Status on Galileo Must do's''' - deferred to next week
 
* McQ - '''p2 OSGi OBR Repositories'''
 
** Jeff: OSGi wants to foster bundle store / bundle repositories, and specify a repository standard (long-standing RFE112 never been ratified)
 
** Similar to p2, but does have some potential issues
 
** Ideally, Equinox would be the reference impl of whatever standard comes up... but got a staffing problem, how to get the solution standardized that we need.
 
*** Writing a p2 OBR repository adapter is not hard, but OBR repos won't be able to eat p2 metadata
 
** p2 doesn't care about XML format whereas OBR specifies the XML. p2 got more sophisticated API model. Jeff doesn't have access to the latest spec.
 
* Steve wants Eclipsecon demos to be done on '''Cocoa''', will expedite any bugfixes (please do file them!). Jeff needs browser integration.
 
 
<hr/>
 
 
'''Mar 4:''' - McQ, Steve, Jeff, Philippe, Martin
 
 
* Upgrade 3.4 -> 3.5
 
** Will we be able to support this in p2?
 
*** Nope, needed hooks already in previous release (ie. needed them in 3.4 to be used by 3.5)
 
** Problems include replacing the Eclipse .exe
 
** Is this an important use case?  There is no band width to solve this problem in 3.5
 
** it's a good showcase for p2 technology
 
** idea: put in the low level hooks for 3.5.1 and use them next time (ie. 3.5 -> 3.6)
 
** Did Update Manager ever do this?
 
*** Jeff: It does not
 
 
* Deprecating Mac carbon?
 
** Apple claims Cocoa is the future
 
** 3.5 will be the last version of Eclipse where Carbon is under active development
 
*** But will maintain for 3.6 and 3.7
 
** Q: Has Apple officially deprecated carbon?
 
*** No but they have down played it (ie. no 64-bit support for carbon)
 
** Should there be an official deprecation policy for platforms?
 
 
<hr/>
 
 
'''Feb 25:''' - McQ, Steve, Martin, Philippe
 
 
* AC "committers should know" mail
 
** '''Following external links''' McQ why not introduce some Javascript on the server that warns users automatically when they follow an external link?
 
** Components to projects flattening (not on our plate at the time)
 
* Steve Target milestones for Eclipse project
 
* BZ patches to be flagged when they contain API
 
* '''N-builds broken''' over the weekend (again) - 3 weekends in a row - no people currently who are willing to work during the weekend
 
** Hudson might help eventually, for now using e4 builds as the guinea pig
 
* '''UI Forms has no committers''' - opportunity for Community to become committer
 
** migrate off (using internal browser instead)
 
** no critical bugs, less than 125 interesting bugs
 
** long-term future is e4 with css/styling and declarative ui
 
* '''Performance:''' No news (not yet while closing down API)
 
** Philippe thinks that the performance milestone must be earlier since performance might touch on API. We're losing memory because rebasing
 
** McQ - this cycle we had a performance run in M2, this year we're in a better position than last year
 
 
'''Feb 18:''' -  no meeting
 
 
'''Feb 11:'''
 
  
'''Feb 4:'''
+
See https://github.com/eclipse-platform/.github/wiki/PMC-Meeting-minutes for new minutes
  
<hr/>
+
March 30, 2022 - Alex, Tom, Lars
 +
* Discussion about simplification of the Github repo structure
 +
* Currently no plan to provide a Github for user to report issues, we rather
 +
* For pull request there should no need to open a bug report / GH issue,  all present PMC members agreed, to be discussed next week with Jay and MQ.
  
'''Jan 28:'''
+
February 16, 2022 - Alex, Tom, Jay, Lars, McQ
 +
* IP log done for 2022-03, process might be removed by the foundation in the future
 +
* Auto-closed policy can now be decided by project, project committer can vote on it
 +
* Support of additional architecture LoongArch and FreeBSD was discussed, for now we expect the builds outside of Eclipse.org for these architures
 +
** building Eclipse might get easier with planned enhancements in Tycho
 +
* Bug reports from Bugzilla are not planned to be moved to Github, will continue to exist in Bugzilla
  
* Java 6
 
** move reference platform to Sun 6u11
 
*** problem(?): Sun added 3 new items added that are licensed LGPL or GPL
 
*** [[Image:Ok_green.gif]] Martin added comment to {{bug|261724}} to identify this issue
 
* ICU 4.0
 
** we will stay with 4.0
 
* Deprecation Policy
 
** still under discussion, {{bug|261544}}
 
* Use of internal provisional
 
** seems to be some consensus about *not* requiring this, {{bug|261874}}
 
* JDT co-leadership
 
** what is the process?
 
*** Jeff: vote in community; then propose to the PMC
 
*** Would like to get Dani Meghert involved.
 
*** Philippe will check development process documents
 
* Cocoa port
 
** Looking good
 
** Taking early access off and making it the "first" choice for Mac downloads
 
* Milestone progress / 3.4.2
 
** Need to discuss M5 in arch call (should have done this last week)
 
** Should always remind the team in the arch call of upcoming deadlines
 
** Performance issues that need API to fix have to happen by M6
 
*** Teams should understand performance results (will be discussed in a couple of weeks)
 
* Re: Reference Platforms
 
** Java6 on Solaris
 
*** Martin's company would like to support this
 
*** [[Image:Ok_green.gif]] filed {{bug|262907}} to discuss process and practices around reference platforms
 
  
'''Jan 21:'''
+
'''January 19, 2022''' - Alex, Tom, Jay, Lars, McQ
 +
* Eclipse aggregator build is currently migrated to Github
 +
* Github migration work of the aggregator is documented in https://bugs.eclipse.org/bugs/show_bug.cgi?id=577323
 +
* The most important PGP work items are done with the help of Ed Merks, some secondary issues are still missing, e.g. such features are shown as unsigned
 +
* JFR Event are discussed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=578055, PMC members should check so that we can discuss it next week
  
* How should we track meeting minutes topic - Wiki
+
'''January 12, 2022''' - Alex, Tom, Jay, McQ
* Provisional API conventions - Jeff working on {{bug|261874}} for discussion at the AC
+
* Move to PGP signed content news to IDE WG and Planning Council
** should there be a tag in the Javadoc (ie. "experimental")?
+
** Well received so far
** Jeff wants to keep the concerns "conventions" vs "Javadoc" separate
+
** 2022-03 to has the implementation, 2022-06 to do full switch
** Jeff, "... Javadoc should not be generated for provisional ..."
+
** we use PGP for content not delivered to Simrel
** Martin disagrees, "... need feedback and discussion for new API ..."
+
** Ed helps with implementation/bug fixes
* What is the '''role of the PMC lead?'''
+
** only concern is critical CVE - that would require either help or PGP signed content being pushed to 2022-03
** global view of components/processes
+
*** To be further discussed if such an issue happens
** organize architecture call, ensure we are on track
+
* ECF relation
** spark conversations (ie. M5 is feature freeze)
+
** Project is heavily under resourced
* '''Reference platforms'''
+
** No one knows good reason to still be using Apache Httpclient, Java HttpClient is not tried out and the previous JVM Http code had severe limitations
** we should choose JDK1.6, "update 11" rather than "update 4"
+
** Development falling out on Platform releng for updates to Apache Httpclient, Windows proxy support and etc. is a no-go
** around "RC time", solidify the reference platform (it is the one we are testing on)
+
** Possible plan
 +
*** Create Java Httpclient based connector for ECF or enhance the current default one to use Httpclient and not Httpconnection - removes need to update Apache Httpclient dependency, take care of windows specific bundles with JNA dependency and so on
 +
*** If previous doesn't uncover limitation in Java's Httpclient stop shipping Apache Httpclient connector
 +
*** Assuming 2 previous complete - look if it makes sense to not have ECF as a dependency at all to skip one cyclic dependency
  
'''Jan 14:'''
+
= Archive =
  
* PMC component ownership x bugzilla pmc authorization
+
* [[Eclipse/PMC/Minutes 2021 | Archive of Meeting Minutes from 2021]]
 +
* [[Eclipse/PMC/Minutes 2020 | Archive of Meeting Minutes from 2020]]
 +
* [[Eclipse/PMC/Minutes 2019 | Archive of Meeting Minutes from 2019]]
 +
* [[Eclipse/PMC/Minutes 2018 | Archive of Meeting Minutes from 2018]]
 +
* [[Eclipse/PMC/Minutes 2017 | Archive of Meeting Minutes from 2017]]
 +
* [[Eclipse/PMC/Minutes 2016 | Archive of Meeting Minutes from 2016]]
 +
* [[Eclipse/PMC/Minutes 2015 | Archive of Meeting Minutes from 2015]]
 +
* [[Eclipse/PMC/Minutes 2014 | Archive of Meeting Minutes from 2014]]
 +
* [[Eclipse/PMC/Minutes 2013 | Archive of Meeting Minutes from 2013]]
 +
* [[Eclipse/PMC/Minutes 2012 | Archive of Meeting Minutes from 2012]]
 +
* [[Eclipse/PMC/Minutes 2011 | Archive of Meeting Minutes from 2011]]
 +
* [[Eclipse/PMC/Minutes 2010 | Archive of Meeting Minutes from 2010]]
 +
* [[Eclipse/PMC/Minutes 2009 | Archive of Meeting Minutes from 2009]]

Latest revision as of 10:39, 28 September 2022

Documents

Some documents written and/or used by the PMC:

Meeting Schedule

The Eclipse Project PMC has a weekly phone meeting every Tuesday at 11.00am EST.

Meeting Minutes

See https://github.com/eclipse-platform/.github/wiki/PMC-Meeting-minutes for new minutes

March 30, 2022 - Alex, Tom, Lars

  • Discussion about simplification of the Github repo structure
  • Currently no plan to provide a Github for user to report issues, we rather
  • For pull request there should no need to open a bug report / GH issue, all present PMC members agreed, to be discussed next week with Jay and MQ.

February 16, 2022 - Alex, Tom, Jay, Lars, McQ

  • IP log done for 2022-03, process might be removed by the foundation in the future
  • Auto-closed policy can now be decided by project, project committer can vote on it
  • Support of additional architecture LoongArch and FreeBSD was discussed, for now we expect the builds outside of Eclipse.org for these architures
    • building Eclipse might get easier with planned enhancements in Tycho
  • Bug reports from Bugzilla are not planned to be moved to Github, will continue to exist in Bugzilla


January 19, 2022 - Alex, Tom, Jay, Lars, McQ

January 12, 2022 - Alex, Tom, Jay, McQ

  • Move to PGP signed content news to IDE WG and Planning Council
    • Well received so far
    • 2022-03 to has the implementation, 2022-06 to do full switch
    • we use PGP for content not delivered to Simrel
    • Ed helps with implementation/bug fixes
    • only concern is critical CVE - that would require either help or PGP signed content being pushed to 2022-03
      • To be further discussed if such an issue happens
  • ECF relation
    • Project is heavily under resourced
    • No one knows good reason to still be using Apache Httpclient, Java HttpClient is not tried out and the previous JVM Http code had severe limitations
    • Development falling out on Platform releng for updates to Apache Httpclient, Windows proxy support and etc. is a no-go
    • Possible plan
      • Create Java Httpclient based connector for ECF or enhance the current default one to use Httpclient and not Httpconnection - removes need to update Apache Httpclient dependency, take care of windows specific bundles with JNA dependency and so on
      • If previous doesn't uncover limitation in Java's Httpclient stop shipping Apache Httpclient connector
      • Assuming 2 previous complete - look if it makes sense to not have ECF as a dependency at all to skip one cyclic dependency

Archive

Copyright © Eclipse Foundation, Inc. All Rights Reserved.