Skip to content

Dev Meetings 2018

Jump to bottom
Vincent Fugnitto edited this page Jan 5, 2022 · 1 revision

Minutes, 2018-12-18

  • Anyone needs a release this week/month? Please ask for it on Spectrum ASAP.
  • Simon Marchi has been voted committer on the project!
  • Next dev meeting on January 8th?
  • Eclipse Foundation Move / IP issues
    • [Marc D] had a talk with Sharon from the Foundation. TL;DR: as suspected we in principle need approval through CQ for any new or updated version, of any our "prereq" dependencies. It's suggested that we have one CQ (per repo?) for all our npm "prereq" dependencies, in which we attach the whole recursive dependency tree (i.e. node_module folder(s) containing production dependencies, rather than opening a new CQ per individual dependency. (non-npm dependencies should have one CQ each).
      • Sharon suggested we ask our project mentor (Gunnar Wagenknecht) to validate our theory of what our "prereq" dependencies are, and work from there. I have reached-out to Gunnar by email, explaining the situation and asking for his help.
      • If/when we confirm with Gunnar that we have more-or-less correctly identified our "prereq" dependencies, Sharon will have an internal discussion about how to make it viable for us to report/maintain our list up-to-date, without impacting our work too much (or the Foundation's limited resources). If/how we can continue to use version ranges, for npm dependencies, will be one aspect considered.
        • -> IMHO some form of automated npm dependencies license compatibility check, done as part of CI for PRs, would be the way to go. If it finds a new or updated dependency, that's suspicious from a license PoV, maybe then the check would fail, merging would be denied and a CQ would be required. Else you'd get immediate merge permission without further action.

Minutes, 2018-12-11

  • Florent: CQs on new dependencies introduced in codebase (I saw like for example new Xterm, new electron but no CQs https://dev.eclipse.org/ipzilla/query.cgi)
  • Florent: E2E tests
  • Committer election ongoing for 3 contributors: Anatolii Bazko, Vitaliy Guliy and Simon Marchi.
  • Eclipse Foundation move: the following new items could push-back our repo's move after the holidays, unless resolved in the next few days:
    • Following expressed concern over one of our npm dependency having potentially GPL code, we opened a CQ to confirm if it's ok to use node-origuma. Analysis by the Foundation is ongoing.
    • It was brought-up, on a PR, that we have no process to deal with new or updated production npm dependencies. It may be necessary to register CQs for these also, not just when we copy code. I have asked clarifications from the Foundation about this. If it's required, we may need to register CQs for all new/modified such dependencies, since the initial contribution scan from the summer.

Minutes, 2018-12-04

Communication and decision making.

We agreed on taking the following actions before starting to work on something:

  • searching / creating an issue and assign it
  • reach out to potentially interested people though gitter or otherwise

Using Electron 3 - is it possible to keep Node.js 8 as the baseline?

We agreed on the following here.

API deprecation

  • What should be considered stable API?
  • When to remove deprecated API? right before 1.0.0?

We agreed not breaking API but use a deprecation strategy where deprecated API is availbale at least for one release-cycle.

Move some packages from main repository (not core packages) to external repositories. cpp, java*, json, debug-nodejs, python, typescript ?

We agreed on keeping everything that is used to develop Theia itself (typescript, json, nodejs debug). Other language features should move to separate repositories. We will eventually be able to reuse the VS Code extensions. Florent and Thomas said it is a couple of weeks away.

The plug-in extension doesn't work on Electron

named: Symbol(extPluginApi) and Cannot find a service for the path: /services/plugin-ext issues in the electron example.

Decision: we disable the plug-in extension in the electron example, and we re-enable it once we have verified it works.

Eclipse move / IP scan update: CQs status: we have permission to "check-in" for all pending CQs! Theia repo move can proceed!

Minutes, 2018-11-27

Minutes, 2018-11-20

  • Eclipse move / IP scan update:
    • A CQ for 3rd party copied code for vscode upstream project registered. See this post to see the list of covered files.
    • A few more CQs are to be opened, for files copied from other upstream projects. In progress...

Minutes, 2018-11-13

  • Eclipse move / IP scan update
  • Multi-root workspaces: keep preference, with feature disabled by default (Liang) ?

Minutes, 2018-11-06

  • publishing Theia Plug-in API typedoc (Florent)
  • Eclipse move / IP scan update

Minutes, 2018-10-30

  • Eclipse Foundation Legal IP Process - compliance refresher: among other things, we need to register CQs for any inclusion of 3rd party code, in Theia. This should be checked-for during reviews, and merging such contributions should be delayed until the corresponding CQ(s) is/are approved. Here's a poster that guides a committer through the "Legal IP Process"
    • I did an md5 checksum comparison between Theia and VS Code repos, and found more of our files were copied verbatim from vscode. The bulk are icons (.svg) and textmate grammars. Looking into using an internal scanning tool that should be better at finding files or snippets that were copied from elsewhere.
    • All such "violations" of the Eclipse IP process will need to be resolved (CQs approved) before we can check-in that code in our new repo. So this delays the repo move. So far we have ~60 new files that will require to be covered by one or more CQs.

Minutes, 2018-10-23

  • no meeting held. Some updates anyway:
  • Eclipse Foundation move: see update at top here
  • Tentative Theia 0.3.16 release on Thursday, afternoon Montreal time.

Minutes, 2018-10-16

  • Eclipse Foundation move: Details documented in GH issue: https://github.com/theia-ide/theia/issues/3182
    • Please have a look at the issue above and raise any objection or concerns ASAP.
    • When? Last week of October? somewhere in Oct [29, 30, 31st]? Objections?
    • [Post-move] Will ask for a IP scan by the Eclipse Foundation, to catch 3rd party code introduced after the initial contribution, without registering proper CQs. Going forward these should be catched during code reviews, and the CQ should be obtained before merging the PR.
    • [Post-move] There is probably a need for the Eclipse Foundation to periodically scan, for potential node-dependencies (non-dev) license incompatibility. When to do this exactly is TBD. Maybe before each release? (note: done once ~2 months ago, using node dependencies from master at that time).
    • [Post-move] What do users need to do after the move?
      • for a normal user, cloning a fresh copy of the repo after the move, would be simplest.
      • for contributors that have PRs and side branches they want to keep, I think it's possible to fetch all new repo's commits in the current local repo and use cherry-pick between old and new branches (making sure the base is the same, so it applies correctly). For PRs created before the move, that are made from a branch in local repo, it might be necessary to re-create the branch locally on the new repo, and push that branch to the new main GH repo.

Minutes, 2018-10-09

  • no meeting held

Minutes, 2018-10-02

  • State of debugging support. How to move forward? Hold meeting on Friday Oct 5th.
  • Eclipse Foundation move update: need to check with Eclipse Foundation if they have the resources to help the move just before / during EclipseCon. Else we can postpone after. Will open Theia issue to track.

Minutes, 2018-09-25

  • Need for non-UI end-to-end testing (simark), https://github.com/theia-ide/theia/issues/2919 Simon is going to try something out. Sven to lookup a framework.

  • Theia 1.0 Plans Rob asked for Theia 1.0 plans. Expected something fro end of October (EclipseCon). Probably too soon, but we want to start the process of discussing what a 1.0 release means and how we can get there. Rob to create an epic ticket.

  • Build per commit, rather than per PR (simark) Simon wants to use git bisect and is afraid that he will run into false-positives if we don't enforce testing against each commit. Sven's concern is longer build times. Rob said most CI tools would cancel running builds on new commits.

  • Heads-up: Theia 0.3.15 release scheduled for this Thursday, September 27th, afternoon Canada time.

  • Eclipse Foundation update: (Marc) busy on other things, no significant progress in last week. Next push after this week's release.

Minutes, 2018-09-18

  • Eclipse Foundation update: CQ #17349 is "License_certified". That was the last registered CQ we have ATM.
  • Running Electron version of Theia, connecting to a remote backend PR: TypeFox tentatively interested in this feature, but may not immediately have the bandwidth to continue the review.

Minutes, 2018-09-11

  • no meeting held.
  • Eclipse Foundation update: no news - Eclipse Foundation IP Team resource was OOO last week.

Minutes, 2018-09-04

  • Eclipse Foundation update: npm dependencies CQ still being analysed by the Foundation. We provided a new dependencies zip attachment that excludes dev-dependencies, that we do not distribute.
  • Note: we need to be careful about introducing 3rd party code in Theia. We have opened CQs for such things, up-to the "initial contribution" commit on June 22nd. If/when we add additional 3rd party content, new CQs will be required.

Minutes, 2018-08-28

Minutes, 2018-08-21

Minutes, 2018-08-14

  • Postponed to next week.

Minutes, 2018-08-07

  • Nothing to discuss. Meeting was skipped.

Minutes, 2018-07-31

Minutes, 2018-07-24

Minutes, 2018-07-10

  • Eclipse Foundation update: Marc will take-over providing a submission where 3rd party dependencies are removed. Next step then is requesting permission for each dependency with CQs. Will do what's possible this week, continue after 1w vacation.
  • vacations: Sven and Marc will both be on vacation next week. If there is something needed that requires a project lead approval, please do it this week. e.g. new git repo created under the Eclipse GH org.

Minutes, 2018-07-03

  • Eclipse Foundation update: we were asked to remove external content from the initial submission. It's not clear if, for a Type A project such as Theia, we will need to submit CQs for these. TypeFox will take care of this.
  • quick demo of (multi-root workspaces PR)[https://github.com/theia-ide/theia/pull/2117]. The UI for this feature are hidden by default, and has to be enabled through a preference: workspace.supportMultiRootWorkspace = true
  • Today: Virtual Eclipse Community Meetup: Eclipse Theia (https://www.youtube.com/watch?v=h1cLiPE-Yno)
  • TextMate coloring: Sven has been adding support for the main languages we support in Theia (Java, C++, Pythin, ...). Covered as well are some small "languages" such as json, yaml and html. Paul mentioned that a bundle exists that permit installing in one step a great number of TextMate grammars, name something like "monaco-textmate-grammars". Maybe this one? : https://www.npmjs.com/package/monaco-textmate-languages

Minutes, 2018-06-26

  • Eclipse Foundation update: Ericsson gave permission to re-license its contributions. Anton has made the "initial contribution", where the licenses are changed (see tag "eclipse_initial"). This has been submitted to the Eclipse Foundation as a CQ, as per the process. When approved, we can squash the repo into a single commit and move it under the "Eclipse" GitHub organization. Until then we can only merge contributions from TypeFox, Red Hat and Ericsson.
  • documentation: what we have in the "readme.md' file, for each extension, is not easy for an end-user to "discover". It was suggested to find a way to (ideally automatically) those readme files or link to them from the theia-ide.org web site. An alternative suggestion is to add this doc to the repo's wiki. "Jekyll"" and "gitbook" were mentioned as potential solutions.
  • Florent created a new Theia "generator-theia-extension but for plugin" repository. He was wondering if he should add this under the theia-ide or eclipse GitHub organization. Either would probably work, but since he's already an Eclipse contributor and the sole author, he can probably save some time by putting it under Eclipse right away. e.g. https://github.com/eclipse/<theia-generator-plugin>. The documentation could be added here: 'https://github.com/theia-ide/theia-website/blob/master/doc/Authoring_Plugins.md', so it's published on theia-ide.org.

Minutes, 2018-06-19

  • Eclipse Foundation update: Ericsson re-licensing permission still pending. Investigating what's the status
  • more transparent Theia planning: As a first step, we agreed to create and use GitHub milestones, on a monthly basis. Then each team would assign issues they think they can deliver, to the appropriate milestone. If an item slips, it can be pushed back to a later milestone. When we release, the list of issues associated to the milestone would be the content of the release.
  • Regular Theia release on the last Thursday of each month. This month it will be on June 28th.
  • Discussion about the "best" way developing against Theia. An issue will be open to discuss this further.

Minutes, 2018-06-12

note: EclipseCon France is ongoing, so many contributors might be busy. Unless someone adds an item to the agenda, we can skip?

  • no meeting?

Minutes, 2018-06-05

  • Eclipse Foundation update: Red Hat now comfortable to give blanket permission to re-license their contributions. Process ongoing at Ericsson. A single individual contributor has yet to respond to re-licensing request.
  • Theia release targeted for tomorrow, to give time to create/review release notes. Going forward, contributors would be encourage to add to that file as part of contributing features, so that it's almost ready, by the time we do a release.
  • React vs. Phosphor

    • Q: Once we have switched to React, can we completely get rid of Phosphor?

    • A: No. We will still use Phosphor for layouting the widgets and React for rendering a concrete widget.

    • Q: As an extension developer, should I use React or Phosphor. I do not want to implement the same thing twice.

    • A: Use Phosphor for layouting but React for the components.

    • Q: Can I use React for my widgets right now?

    • A: Once the [Statusbar] React migration PR is merged, you can use React for your components.

Minutes, 2018-05-29

  • Eclipse Foundation update
    • Red Hat contributors to go through same process as individual contributors, for re-licensing purposes
    • no need to take side-branches into account, for the re-licensing. When they are ready to be merged, post-move to Eclipse Foundation, they can use the normal Eclipse process (CQ, ...)
  • the want/need for a common way of planning/scheduling what we each work-on, was mentioned again. e.g. GitHub Projects

Minutes, 2018-05-22

  • Eclipse Foundation update: Gathering of consent for re-licensing contributions, from individual Theia contributors, is progressing well: only two out of eleven have not responded yet. In one case, for a minor documentation update, the contribution is owned by a previous employer. All others that have responded have given consent. In parallel, we are looking into getting permission for TypeFox, Ericsson and Red Hat contributions.

Minutes, 2018-05-15

  • Eclipse Foundation update
  • Security advisory for deep npm dependency
    • npm can now report security issues related to installed / locked dependencies.
    • Theia indirectly includes "compromised" packages as dependencies of its own dependencies.
    • Solution?: Find new versions for our direct dependencies that will also use more up-to-date dependencies that would fix the various security issues.
  • Theia release planning, community roadmap
    • How does the Theia community decide what will happen for the next release, where do we document what happened in the last release, when do releases happen?
    • Sven confirmed that creating release notes and publishing a release schedule makes sense
    • The team doesn't do regular sprints, the goal is an always-releasable trunk. Typefox uses nightlies.
    • Does the team have long-running feature branches for more disruptive changes? Yes - goal is to make changes smaller and merge more regularly, unstable/experimental features can be disabled by default
    • Marc and his team do tag releases every month in github, and rely on stable releases internally, but they do not do any special stabilisation work
    • Goal setting: Marc said that there is a known set of high level goals (~1 year) but how we re-prioritise work to get towards the goal is done much more often. Sven said that he has a roughly 1 month long view of what the team will be work on, revised often.
    • One idea: We could use github projects to schedule and plan releases. Tagging releases once a month sounds like a reasonable goal. We could also use milestones to track what went into a release, and what is planned for the next release.

Minutes, 2018-05-08

  • Eclipse Foundation update: The project provisioning process is complete. See here for details
  • next step: squash and move our theia-ide/theia repo to the Eclipse foundation organization. Will need to plan this to minimize impacts.

minutes 2018-05-02

(Attention: due to holidays in Europe, this meeting is pushed back to Wednesday, same time)

  • How should we update the year attribute in the copyright headers? Recently a few PRs flipped the year from 2017 to 2018. Answer: Our linter rules already support the following way: Add the new year to have a range; 2017 will become 2017-2018. Later, 2017-2019.
  • Syntax highlighting: try to make vscode-textmate work in F-E, using OnigurumaASM.
  • Discuss Electron's connection to remote B-E: Ideally we should try to use the F-E application that is served from the remote server (the same one that would be served when connecting to that B-E using a browser), instead of the local one. That avoids issues of version mismatch between the two. If we can't get that to work, then versioning the protocol might be a fallback option.
  • Timeout issues when publishing @theia/java: to avoid timeout, we should try to do download jdt in npm module post-installation, instead of bundling it.

Minutes 2018-04-24

Minutes 2018-04-17

  • Eclipse Foundation update: The new "Eclipse Theia" project proposal is now public and open for comments. It has to stay up for a minimum of two weeks. In the meantime, other activities will start, like IP and trademark checks. See here for more details about the process.

Minutes 2018-04-10

  • tslint: Agreed to go with 2 files as before in the case if new rules introduce more warnings. Simon will take care about it.
  • logging: TypeFox concerned that logging is not the end user responsibility. Gorkem proposed to use env variables to configure logging levels. Sven suggested to use a configuration file for it. Ericsson mentioned changing log levels at runtime can be useful to help find issues in the production. Mark mentioned that it can be achieved with watching a configuration file.
  • multi-root workspaces: Ericsson will work on the initial prototype. The complete LSP support requires updating vscode-base-languageclient and monaco-languageclient. Gorkem mentioned that for the initial prototype one language server per each project in the workspace can be started similar as it was done for Eclipse Che and VS Code at the beginning. Ericsson asked to share the knowledge how to update LSP related projects.
  • Jest: Nobody knows why it should be done. Jacques mentioned that we had issues running test in the same thread. Anton mentioned that the PR introduces more changes than before. Agreed that someone should take time to try it out and learn if there are real improvements for Theia.

Minutes 2018-04-03

  • Eclipse foundation application: Sven heard from Ericsson contact that a decision / way forward is imminent. Ericsson Theia dev team has had no news about this yet.
  • Quick discussion about a Theia application problem, when trying to specify older versions (before "latest") of extensions, as reported in a recent issue. The Theia extensions dependencies specify "greater or equal to current" (e.g."@theia/core": "^0.3.7"), which can ends-up pulling multiple versions of some dependencies. This results in some classes being duplicated, which usually breaks the application at runtime. Sven clarified that in the end it's a problem with the behavior of yarn, that should ideally find a single version of each dependency that satisfies overall. An issue about this was opened a while ago on yarn, by Anton. In the meantime a w-a is to use a "resolutions" block in package.json to specify the wanted version for all Theia extensions, directly or indirectly used in an application.
  • About Using React: Ericsson previously had reservations because of the license. Internal inquiries have been done to confirm if it's now ok, following the license change - waiting for a response.

Minutes 2018-03-27

  • Meeting time: Will change to 2pm UTC to keep it at same time as before we switched to daylight saving time.
  • Theia release tomorrow, March 28th. Will give a "heads-up" on gitter before.
  • Consider using React instead of Phosphor virtual DOM (which looks like it's being deprecated). There are multiple technical advantaged to React and a much bigger group of developers are familiar with it. Ericsson previously had objections to using it because (at least in big part) of its license, that included a controversial patent grant. Since it's no longer the case, we will reconsider.
  • a meeting to discuss the new extension system will be held later this week.

Minutes 2018-03-20

  • We will do a Theia release next week, On Wednesday March 28th. Ericsson will publish Theia and TypeFox will update for API changes and release extensions they have authored, that reside outside theia-ide/theia
  • Red Hat are internally discussing the design for the proposed new "sandboxed" extension system #1482. It seems everyone would like the new extensions to have some sort of VS Code compatibility, but there is disagreement whether it should be directly compatible to through some kind of adapter. This is an important component and so should be discussed openly, before too much effort has been invested.

Minutes 2018-03-13

  • next scheduled release? It's been a while and some nice features have been added since. Can discuss this next week.

Minutes 2018-03-06

Minutes 2018-02-27

  • Avoiding conflicting work. We had an issue where two devs started working on the same issue. It was caused by a duplicate ticket, so our approach using the assignment flag didn't work. We decide to not change anything regarding the process, for now. Gorkem suggested to add a label 'in-progress' if we want to signal that someone is actually working on something already.

  • Gorkem asked about the process of moving Theia to Eclipse. Ericsson needs some more time (approx. two weeks) before we can make the proposal public.

Minutes 2018-02-20

  • Florent about installing/uninstalling extensions without requiring rebuilding the frontend in webpack. Will open a ticket to further discuss.
  • [Metrics] Metrics as a cross-cutting feature should not add a dependency to Prometheus. Patrik to open a ticket to further discuss the architecture of metric contributions. Anton will comment on the concrete case of adding information about extensions.

Minutes 2018-02-13

  • Antoine Tremblay is leaving Ericsson. His new work is unrelated to Theia

Minutes 2018-02-06

  • Move to Eclipse Foundation

    • update about preserving GitHub project history:

      • It seems mandatory that we squash the history when we move to the Eclipse Foundation. However the history will be put in a hidden branch, where it can be discovered. more details here

    • update about Type A project consequences

      • The following were provided: blog post, and see section IV.B in this pdf
      • Marc D's layman's interpretation: the fundamental licensing rules are the same whether a project is Type A or Type B. However with a Type A project, the project itself is left to enforce those rules, and might decide to do so in a more lenient way than the EF would.
  • misc

Minutes 2018-01-30

  • Move to Eclipse Foundation

    • Current Status: Proposal not public yet
    • We want to use EPL2
    • We want to use Github infrastructure.
    • Actions:
      • Clarify with EF how much of our Github project history can be kept
      • Type A Project consequences?

  • Offline Indication (https://github.com/theia-ide/theia/issues/1155)

    • We will go with a simple solution, that lays over a modal layer, telling the user she is offline.
    • Based on a simple GET method

  • Keybindings

    • Sequences longer than 2 are not shown in the Command palette
    • Sequences longer than 1 will not be shown in Electron

Project Management

Documentation

Clone this wiki locally