Skip to content

Eclipse IDE ‐ Developers Community Call

Jump to bottom
Hannes Wellmann edited this page Oct 10, 2024 · 21 revisions

Upcoming and past meetings are listed in the Eclipse IDE Community calendar

Objective

Everyone that participates or is interested in participating in the development of the Eclipse core itself is invited to join, newcomers are explicitly encouraged to join too. It is planned as an open meeting without a fixed agenda, where everyone can suggest to discuss general or specific topics, changes or issues or can ask questions. This call is dedicated to the development of the core of Eclipse itself, mainly the top-level projects Eclipse-Platform, Equinox, Eclipse Java development tools (JDT) and Eclipse Plug-in Development Environment (PDE). It is not intended to provide support for users or consumers of Eclipse, for that other channels exists. If specific issues or changes are discussed, the exchanged arguments should be summarized in the corresponding issues or Pull-Requests and if decisions are made they should be justified. Of course others not participating in the call should still have the same chance to influence a decision.

Meeting minutes

  • 13th June 2024

    The following topics were discussed

    • General discussion about 'Corporate Capture' of Eclipse and how it affects the innovation at Eclipse in general and about how to improve the founding situation of smaller, yet essential projects.
    • IDE UI "is very chaotic. For example, the context menus are very disorganized. How could they get cleaned up in a meaningful way?"
    • "The documentation is overwhelming for beginners and good resources are hard to find."
      • "It's all there but especially the official resources/docs are hard to find"
      • "Many unrelated things on the main page"
        Suggestions to consider a clean-up of or to make the documentation leaner

    Because of overwhelming doc and UI the suggestion was made to discuss if the the position of EPPs Packages should be strengthens with a product-owner for each package that makes sure the default content of these packages looks good and the documentation is cleaned up.

  • 27th June 2024

    The following topics were discussed

    • Discussion about the requirement of the Eclipse-IDE respectively the requiring Java-21
      • It would be nice to inform the user better during the update-process, for example show a corresponding dialog in the IDE.
      • Discussion about if/when Eclipse SDK/top-levle projects should require Java-21
        • Set up rules for Eclipse SDK/top-level projects (PMC TODO)
        • Suggestion to add code that uses
        • Code that uses Java-22 Foreign Function and Memory Access API could be placed in dedicated fragment to be usable before Java-25 is used in general.
    • Appeal to re-use existing images or shared images to not replicate e.g. a close icon in 20 bundles (which is currently the case). It unnecessarily increases the size of an installation, the required memory at runtime and the time to load all images. Problem: Icons are resources and not 'API'.
      • Images in platform plugins are quite stable.
      • Suggestion: Generate constants (e.g. by PDE) that represent contained resources and provide coordinates to access them. The class and its constants are API and therefore the resources implicitly become part of the API, which can be checked with existing tools. Issue created: https://github.com/eclipse-pde/eclipse.pde/discussions/1315
      • It should be discussed and stated if the path of the referenced resources within the bundle may change and if the content of the resources may change, while preserving the purpose. E.g. may a close-icon be redesigned while still being a close-icon.
    • Short discussion about API-check failures in CI builds due to 'Component was disposed' errors, but no immediate solution is known.

  • 18th July 2024

    The following topics were discussed

    • How to simplify the contribution process or what are the current pain-points during contributions, for experienced and new committers?

      • Unexpected build failures

      • Provide and document a clear way to set up a developer IDE for contributions to Eclipse There should be a "gold standard for how to setup as a new contributor". Of course different ways are possible but one only 'ideal' way should be recommended and described (describing all can be confusing).

        • One suggestion was to replace the Eclipse Committer Package by a corresponding Oomph configuration based on the Eclipse-SDK?

      • There is no Report a bug button in the IDE that leads to a place where one can start to report a bug or gets instructions how to contribute.

  • 1st August 2024

    The following topics were discussed

    • We now own the https://github.com/eclipse-ide Github organization
      • Content is work in progress
      • Is intended to become in the future the main starting point for contributors of code, reporters of issues, developers
        • Should become the target of the Contributing menu entry in the IDE in future
      • Suggestion to add a guide to find the right repository to report an issue or to start contributing
        • It is to be decided if the eclipse-ide organization should also provide a general purpose issue tracker for IDE related issues, that are then redirected (with the help of EF-infra team tooling, Otterdog based?) to the right target
      • TBD: How to assemble/maintain a list of projects/repositories related to the Eclipse-IDE there
        • All from SimRel? Or let projects opt-in and let them provide a short description
        • Generate it automatically from the list of Eclipse projects?
        • Explain that an Eclipse installation can also contain third-party Plug-ins (e.g. from Marketplace)
      • Guide to extract the corresponding issue from a error-message/stack-trace e.g. from error-log
        • Remind that error-log can be source of valuable information
      • Suggestion to use Mylyn to help identifying the desired repository to report an issue/start contributing and to e.g. see issues.
      • Provide a Codespace/Gitpod/web-container like environment for Eclipse development
        • Suggestion to contact Gitpot, since people who used to be at Eclipse are involved
        • Could be a bigger task

  • 15th August 2024

    The following topics were discussed

    • How to handle the current state of the modernized theming?

      Create an opinion poll, to gather feedback from the community (open till Tuesday 20th of August 23:59 UTC). Poll is non-binding, final decision is made by Committers. Send it to cross-platform. Options:

      • Only keep the modernized light-theme as default
      • Keep old light-theme as another/second Light Classic/Legacy separate theme (allows opt-out of the modernized theme) How long it's kept it is another question, but it will not be maintained by the providers of the new theme
      • Provide the new light-theme as a new Modern Light theme (opt-in)
      • Revert the new light-theme for the release and reapply it in the beginning of next development cycle (effectively option 1, but delayed)

      Keeping the old theming could act as a save guard in case severely broken elements were not discovered before the release and gives more time to those that need to adapt to it. However that is only possible for the light-theme. Because the dark-theme as a lot of extensions it would be too much work to provide more than one dark-theme.

    • SWT Edge Browser https://github.com/eclipse-platform/eclipse.platform.swt/discussions/1406

  • 29th August 2024

    The following topics were discussed

  • 12th September 2024

    The following topics were discussed

    • State of Linux/Wayland support in SWT
      • At the moment only latest LTS of Ubunutu/Suse/REHL is fully supported, but Wayland will become important in the future
      • Suggestion to clarify in the API documentation of known limitations on some platforms that cannot be resolved (e.g. due to design decision of that platform)
      • Win32 API might change soon too that need adaption for SWT on Windows
    • Discussion about Marketplace client issues in the new release integration
      • Some background information
    • A summary of the PMC's decision about rules when new java versions are permitted to be used as required execution environment of a bundle were given
      • The details will be published in written form soon

  • 26th September 2024

    The following topics were discussed

    • Current state of UI-refresh and how to proceed (https://github.com/eclipse-platform/eclipse.platform.ui/issues/2114)
      • Should the theme be tailored for IDEs (with an Editor as 'main actor') or should it be designed for general RCP applications focused
      • Suggestion to keep the old theme for now in a separated file in the git-tree (but not deliver it) as a public archive so that those interested can easily fetch it and maintain it if desired.
    • State of AI support in Eclipse
      • Prerequisites are getting in shape
        • Edge Integration
        • Code-Mining (for 'ghost text')
        • Extraction of the IDE context to feed it back to a LLM
    • Call for actions to flag more issues as 'Good first issue'
    • Report about resolution of identified contribution obstacles (discussed in #18th-july-2024):
      • Workflow for automatic version bumps is being rolled out
      • Tycho 4.0.9 does not display a JGit error in the end anymore
    • How to keep the number of attendees to this call up? Without prior notification this attendee count significantly declines)
      • Link the dev-call in the Contributing section of the TLP repos and spread the word in issues/PRs.
      • Keep the notification mails (those that are not interested will eventually filter them).
      • Have potential topics pre-selected and listed in the reminder mail
        • Open discussion remains possible and input is more than welcome

  • 10th October 2024

    The following topics were discussed

    • Report about the progress in SVG support for SWT.
    • Question if there are existing users of the linux.ppc64le port of SWT and Eclipse/Equinox
      • If it is not used and nobody is interested in the maintenance, we consider dropping it to reduce future maintenance effort.
    • Raised the question if it's possible to systematically fade-out support for older OS versions, mainly in SWT
      • Idea was to add OSGi requirements and capabilities, but it's hardly feasible to correctly determine the capabilities at runtime correctly.
        • Some APIs are added only with specific updates
        • E.g. Under Linux different distributions deliver different versions of libraries or even patch them.
    • Heads up that PHP on eclipse.dev project websites will not be supported anymore by the EF after December
    • No call in two weeks because of EclipseCon/OCX 2024
      • Meeting will be removed from calendar, but no reminder/announcement will be send (drops the number of participants any ways).
Clone this wiki locally