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"

 
(908 intermediate revisions by 15 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 =
  
'''Nov 4:'''
+
See https://github.com/eclipse-platform/.github/wiki/PMC-Meeting-minutes for new minutes
 
+
 
+
<hr/>
+
'''Oct 28:''' - McQ, Dani, Martin, John
+
* McQ - vacation for 2 weeks: Dani to do the calls, John to do the status messages
+
* McQ, Dani - IntelliJ gone open source; but not making the J2EE part open source; GUI designer and XML tooling is open source; JUnit and TestNG integration; svn integration out of the box
+
** Seems to be a very liberal license - pulling in the UI designer into the Eclipse world might be an option
+
** We need more information
+
** '''Pre-integration''' of stuff: Could we have a "Get more stuff into Eclipse" menu item that auomatically grabs the popular stuff, rather than offering the more complex repo choices we have today
+
*** Or, lazy loading: E.g. click on a docs stub, open a dialog to install the docs
+
*** Address the casual end users like "Hey I just want to edit some XML"
+
** Martin: This is the "product" vs "framework" discussion which has come up before
+
** McQ: perhaps it is just a question of level of indirection?
+
** Martin: Yes but who is going to actually put resources on that?
+
** McQ: must have a solution in the base (the Platform)
+
** Martin: That would be great, then we can approach the AC with a much stronger background
+
** McQ: want to be competitive. Will know more about resourcing by Nov 16.
+
** John: Already have a plan for some groundwork for this in 3.6. Some Mylyn solution exists on top of p2.
+
** '''AI Martin''' put the item on the AC agenda
+
* Martin - Follow up on Oct 14 McQ '''Official Eclipse Platform Deprecation Policy'''
+
** John - Concerned about putting semantics on "Marketing numbers" for the releases. Focus on the time ("2 years") rather than releases.
+
** John - What about upstream projects? E.g. ECF had a major release
+
*** McQ - cannot make decisions for other projects. If I can only move when everyone else moves, we get a deadlock. Would like to only commit to version ranges that are re-exported
+
** '''AI''' continue discussion on the mailing list
+
 
+
 
+
<hr/>
+
'''Oct 21:''' - McQ, John, Dani, Martin, Jeff
+
* McQ - '''backward compatibility''': struggling more with maintaining backward compatibility than hoped
+
** 12000 references to "internal" in IBM products (RAD) according to API - mostly due to verbatim copies of Platform code, will need better API tooling to get rid of these false positives -- e.g. by grouping together by "copied package"
+
** IBM may need to keep the shape of internals alive when refactoring code
+
** Keep 3.x in place as is. Do any larger API changes in e4.
+
** Jeff - consumers need to understand that there is a lot of work being put into API, and it requires consumer's feedback / interaction
+
** If non-IBM committers need to break internals, they are allowed to do so. If IBM people need the internals, they will invest time to work around that again.
+
* Jeff - '''retention policies in the Galileo Repo'''
+
** Just keep on everybody's radar. Getting this right is VERY important for the entire community.
+
** We got some good stories in p2, but these don't mesh very well with mirroring (unless the entire repo is mirrored)
+
** Martin - discussions in last EAC call: Maven has long history of keeping old versions alive, Andrew Overholt mentioned that making access to old versions too easy may also be a problem
+
 
+
 
+
<hr/>
+
'''Oct 14:''' - McQ, Dani, Martin
+
* Dani '''Nightly Builds''': More builds broken. Need to take more care for the builds.
+
* Martin '''e4 and the AC''': AC wants monthly e4 updates; Question about 4 competing declarative UI technologies
+
** The switch between being in the "incubator" and being the "Eclipse SDK" needs to be "what are we using ourselves"?
+
** Until we use e4 ourselves to develop, it's going to remain in the incubator. At the time we switch over, there will be one or more winning technologies.
+
** McQ to join AC calls, Martin to remind timely.
+
* Martin '''AC - API Deprecation Policy''' should be published, projects want to follow the Platform lead. '''AI McQ''' write something down
+
 
+
<hr/>
+
'''Oct 7:''' - John, Dani, Martin, Jeff
+
* Martin: '''How to run the performance tests'''
+
** John: See [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.test.performance/doc/Performance%20Tests%20HowTo.html?view=co web doc]
+
** Dani: Frederic working on a tool for displaying results, he's still the man to ask in case of questions.
+
 
+
<hr/>
+
'''Sep 30:''' -  
+
 
+
<hr/>
+
'''Sep 24:''' -
+
 
+
<hr/>
+
'''Sep 17:''' - McQ, Dani, Martin, John
+
* John: '''CQ Process''' - The PMC's +1 is not for reading the code but for verifying that "we want this" on a high level. Bring dubious ones to the PMC as a group.
+
* McQ: '''Java 5''' - there are few plugins which may want an earlier Execution Environment, but it makes sense to drop the 1.4 Reference Platforms (need to communicate this to IBM).
+
* John: '''Component Milestone Plans''' - bring up in the arch call
+
* Martin: '''AC Representation''' - McQ to lead, John to second
+
* Getting ready for M2, signing off for 3.5.1
+
 
+
<hr/>
+
'''Sep 10:''' - McQ, John, Jeff
+
* '''Java 5'''
+
* Jeff: '''Apache Aerius'''
+
* '''e4 progress'''
+
 
+
<hr/>
+
'''Sep 3:''' - McQ, Dani, Martin, John
+
* John: '''New 3.6 plan''' - consider removing 1.4 as reference platform, talk to Runtime guys at IBM
+
* Dani: '''Doc Features'''
+
 
+
<hr/>
+
'''Aug 26:''' - McQ, Dani, Martin, Jeff
+
* '''New Sat4j version''' - RT PMC decided to take it out again, so not an issue
+
* '''Separating docs from the code?''' - Dani to post respective bug on the pmc mailing list
+
* '''e4 status updates''' - Jeff interested in regular e4 updates on the pmc
+
 
+
<hr/>
+
'''Aug 19:''' - McQ, Dani, Martin, Jeff, John A
+
* '''Pruning inactive committers'''
+
** Martin: The EMO [http://dev.eclipse.org/mhonarc/lists/eclipse.org-project-leadership/msg00000.html recommends removing inactive committers] in order to keep the project vibrant and relevant. Why are there so many non-voters?
+
*** Dani: Component Granularity - Portal is still broken for JDT UI vs. JDT Core.
+
*** Martin: Yet there are likely some who really haven't been active for long -- but only component / project lead would know that
+
** McQ: We are not actively searching to prune inactive committers. Committers are good, whether active or not. No interest in doing any work for this, but OK if others do.
+
*** Jeff: sees some sense in pruning the list, and did so in the past for Equinox
+
** Rights - what can we actually do in the Portal?
+
*** Component leads can mark people active who appear inactive on the portal
+
*** Only [http://dev.eclipse.org/mhonarc/lists/eclipse.org-project-leadership/msg00002.html The Project Lead can decommitterize], and can do so without PMC interaction
+
**** Jeff - it's odd that this is not symmetrical to approving new committers
+
** John: Once a committer is emeritus and decides to come back, can we make the process of re-making them a committer easier?
+
*** Jeff thinks that the normal committer process is good in this case.
+
** '''Consensus:'''
+
*** We do not actively ask to remove inactive committers, but if a component / project lead wants to do so, they are welcome
+
*** The process is to first send E-Mail to the potentially inactive committer and if they agree they are [http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg04309.html decommitterized] and optionally turned to [http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg04324.html committer emeritus]
+
*** If the E-Mail doesn't work any more they can also be decommitterized immediately.
+
* '''Reference Platforms'''
+
** Going through the process of refreshing reference platform list for Helios
+
** Currently considering: Switch to SLES 11 from SLES 10, add Windows 7, add Ubuntu LTS 9.04, add 64-bit Eclipse for Linux PPC-64 (possibly replacing 32-bit Eclipse for Linux PPC-64)
+
** If you have additional platforms or upgrades to consider, send a note on eclipse-pmc or mention during a PMC call
+
* '''Bugzilla: LATER / REMIND states'''
+
** 4000 bugs affected. Need to discuss in the arch call how to proceed.
+
** Dani Proposal: LATER --&gt; WONTFIX / REMIND --&gt; INVALID / and move back to the inbox since often assignees no longer active
+
 
+
<hr/>
+
'''Aug 12:''' - McQ, Dani, Martin, Jeff, John A
+
* '''Retrospective Actions''' -
+
** Need to nominate a person to care for performance: Dani to try find somebody from JDT core for a bounded time (6 months or so)
+
** Build issues
+
** Bugzilla performance etc
+
* '''Backward compatibility'''
+
** Reporting tool - want a foundation database, that Members can report their API / non-API usage signatures into
+
** Part of the member value-add
+
** KNOWING the impact is the first important thing
+
* '''Forward compatibility''' - from RT / Christian Campo
+
** PDE never tried to ensure that somebody can use 3.4 to launch 3.5
+
** The differences in launching 3.4 vs 3.5 are small... if we would have been aware, we could have made this possible
+
 
+
<hr/>
+
'''Aug 5:''' - McQ, Dani, Martin, Jeff, John A
+
* '''Security proposal''' on eclipse-pmc list - agree that this should be closer to the target runtimes (wtp, ...)
+
* '''"Plugin" vs "Bundle"''' - Clarification: Proposal was only about PDE. Global replacement is out of reach.
+
** McQ thinks that Plugin is a Bundle that makes use of the Eclipse extension registry (plugin.xml) - Jeff disagrees wrt declarative services
+
** As a message to end users, does it help us if we talk about "plugins"?
+
** Is this an internal statement about tooling, or something we should do more globally?
+
** Real problem is, that people should perceive PDE as tooling for bundles: Make Eclipse more adoptable in the OSGi community
+
** "Bundle" and "Plugin" have been used interchangeably for about 5 years... but still, a more pervasive change would require lots of docs changes that may be very painful for consumers
+
** McQ wants a technical proposal what should be changed
+
** Perhaps provide a '''separate''' tooling for bundles (with property files replaced)? EPP Package for Bundle Developers? - But a choice is not a good thing...
+
** '''Jeff suggestion:''' Do PDE 3.6 that is "all bundles" plus add a compatibility bundle that gives you the word "plugin" back.
+
* McQ: '''Backward Compatibility''' - consuming new versions of Eclipse is still too hard. IBM makes it the highest priority that '''everything''' that ran on 3.5 also runs on 3.6 - including internals - or the new version may not be consumable!
+
** Do anything that may not be easily backwards compatible in the 4.0 stream rather than the 3.x stream.
+
** Jeff thinks this is going to be a hard sell because internals are made to be internal
+
** Jeff: API Tooling that allows people to discover use of internals, see also {{bug|261544}}
+
 
+
<hr/>
+
'''Jul 29:''' - McQ, Dani, Martin, John A, Jeff
+
* Dani will start to organize [[Eclipse/Galileo/Retrospective]] items
+
* Too many broken builds recently
+
* e4 shipping 0.9 this week
+
* PDE project proposal coming to explore Eclipse build technology
+
 
+
<hr/>
+
'''Jul 15:''' - McQ, Dani, Martin, John A, Jeff
+
* Dani: What to do with the [http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg08660.html Galileo Retrospective] items? Which ones should become action items? E.g. Bugzilla Slowness?
+
** John: Next PC meeting is Aug 3, should have items for the PC ready by then
+
** Decision: PMC mailing list conversation, will review retrospective action in Jul 29 PMC meeting.
+
* McQ to send out a note to formalize John as the PC representation
+
* McQ wants status messages again for the arch call
+
 
+
<hr/>
+
'''Jun 24:''' - McQ, Dani
+
* Dani asked whether the PMC meeting notes are targeted for the public
+
** McQ: yes, they got announced on pmc mailing list
+
* no PMC call next week due to a holiday
+
 
+
<hr/>
+
'''Jun 17:''' - McQ, Dani, Jeff, John A, (Martin joined just as we were hanging up)
+
* Dani asked whether the PMC had internal discussion of new committer votes
+
** A: Generally the PMC member for the component gives +1, unless they feel the need to bring the discussion to the rest of the PMC
+
* Jeff mentioned that we should remind the teams to do retrospectives
+
 
+
<hr/>
+
'''Jun 10:''' - McQ, Martin, Dani, Steve, John A
+
* Welcome to Dani, John agrees to be here as a listening member for a while
+
* Sun Java 6u14 (May 25) broken for debugging because thread ID's are changed when garbage collector runs
+
** Clearly a Sun bug (also happens in jdb) but not yet confirmed by Sun
+
** Described in Readme, but readme will only be available when a rebuild occurs
+
** Dani will send out a note tomorrow when they know more about other platforms
+
 
+
<hr/>
+
'''Jun 3:''' - McQ, Martin, Steve, Jeff
+
* McQ - asking Dani M to join the Eclipse PMC to represent JDT. PMC agrees. McQ will send a note to Mike Milinkovich / EMO.
+
* McQ - asking John A to represent the Eclipse Project on Planning Council
+
** Jeff thinks that the PC rep should be a PMC member in order to have a strong bi-directional communication path.
+
** McQ proposes asking John to join the PMC calls for communication.
+
** Martin agrees provided that John is OK with this delegate role.
+
* Steve {{bug|277713}} critical bug, probably more critical bugs to triage - defer to arch call
+
* Jeff Target Provisioning discussion
+
 
+
<hr/>
+
'''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:'''
+
  
<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.