Skip to content

Dev Meetings 2019

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

Minutes, 2019-12-17

  • Next dev-meeting? Jan 7th? Jan 14th?
    • Added an entry above for Jan 7th - if someone adds items, a meeting will be held. Else we continue on Jan 14
  • Reminder: release 0.14.0 this week
  • [Jacques] Should we put the Dev meetings summary in a yearly sub-folder?
    • would perhaps be more tidy, but lose ability to easily search across all minutes of meetings
    • no strong opinions one way or the other, current way seems to work fine
  • [Marc] vscode-builtin-extensions: publishing "next" on GH more difficult than anticipated. For now will commit the vsix packaging part so one can easily get the built-ins locally or from Gitpod
    • Marc then to make a manual GH (pre-)release, using vscode 1.39.1 baseline (as requested by Red Hat)
    • Interested people can help test the pre-release, and when we're satisfied, we can make it a solid release
    • This release can then be used to update example applications and others, to use vs code extensions instead of some of the Theia-specific extensions.
  • Anton mentioned the theming feature he's working on. It will break Theia extensions that make use of current Theia theme colors, being replaced with vscode's.
    • Better to wait for next month, when it can be merged earlier in the release cycle, giving some time to extenders to adapt
    • The upcoming PR will be the place to discuss this.
  • NSFW file watcher: some concerns about this dependency - does not seem to be very actively maintained.
    • [ARM] have some unspecified issue(s) with it (feel free to update here!)
    • In the beginning we used Chokidar, but it would perform a workspace scan at startup which would affect performance with some workspaces
    • There are potential theia-level optimizations to be done with file watchers. e.g. each client using a common workspace will have their own set of duplicated watchers

Minutes, 2019-12-10

  • Theia release 0.14.0: On December 19th, instead of Dec 26th? No objections!

Minutes, 2019-12-03

Minutes, 2019-11-26

  • Theia v0.13.0 release tentatively planned this Thursday November 28th
  • Florent: Eclipse Che/Theia PR check
    • Is it ok to report Che failures in Theia PRs? No objection to give this a try. Report failures by posting a message to the PR that breaks Che. The idea is to be aware earlier that this happens, not to block merging of PRs that affect external applications.
    • the same idea could be useful in other cases, like some of our applications under theia-ide, like those in theia-ide/theia-apps and example apps like the one in eclipse-theia/theia-cpp-extensions
  • Rob: Package dependency strategies
    • This is about Theia extensions depending on each other. There are things not working well ATM. e.g. some extensions depend on other ones only to get some needed API definitions, but then the implementation is also added to the Theia application, when sometimes not wanted. As well, even though Theia extensions are thought to be modular (only include those you need for a given app) the inter-dependencies that exist make it so that in practice it's hard/impossible to have applications that build/work without including most of the platform extensions.
    • suggestion: split Theia extensions so that they are granular enough to be able to only use what's wanted, in a given application
      • downside: will be a lot of work, will potentially explode the number of extensions in the repo
    • suggestion: improve things "from the ground up" - fix specific issues instead of having a generic solution
    • Rob opened the following related issue: #6645

Minutes, 2019-11-19

  • CQ for FFmpeg bundled with Electron 4.2.11 is license_certified, completing the checks for that version of Electron
  • @theia/cpp extension has been moved to eclipse-theia/theia-cpp-extensions repo. The intention is to simultaneously release extensions from that repo, at the end of each month. We can monitor the C/C++ apps in theia-apps repo to detect if breakage occurs on next versions between monthly releases.
  • Zulip trial for "dev" matters, as potential replacement for Spectrum: it does not seem that anyone is using it ATM. Is it a "critical mass" issue? i.e. no one uses it so not one uses it? Other reasons?
    • seems that spectrum is not "bugging" people as much as it did a while ago. Notifications are still not working well, but that's arguably a feature, once one knows to refresh the page, instead of being interrupted at random times
    • Zulip is still there is we eventually need it
  • Newly announced Eclipse 3rd party dependencies process
    • looks similar to the experimental process we have been under for a while - we were probably the dry-run, and it looks the results were satisfactory
    • intention to automate the license checks. First will offer a CLI tool, eventually could be wrapped into a GH CI integration like the CLA check.
    • Sharon presented about this at last EclipseCon. Abstract, slides and video of presentation

Minutes, 2019-11-12

  • CQ for Electron v4.2.11 bundled FFmpeg library: progress made
    • found a way to extract only the sources that contribute to the final library - hopefully this will alleviate the Foundation's concerns about potantial GPL code being included. Will update CQ with latest info today.
  • [Sven] Electron 7: could we consider going with that version directly?
    • VS Code uses Electron 6 ATM
    • we should involve Rob - can happen offline

Minutes, 2019-11-05

  • Meeting time: until the spring, the meeting time is 3PM UTC (i.e. back to the usual local time: 10:00 Americas, 16:00 Europe)
  • SCM support via Theia vs VS Code extensions: https://github.com/eclipse-theia/theia/pull/6381#issuecomment-545389965
    • long term we want to remove @theia/git and use vs code extension instead
    • the current git history view can be preserved as its own (renamed) extension if it's useful still, e.g. to show Mercurial commit history.
  • VS Code extensions vs Theia extensions: which to use in main repo?
    • we want to concentrate our efforts towards what brings highest value. So in cases where we have duplication, we probably want to use the VS Code extensions.
    • pre-requisite: having the VS Code built-in extensions included is important because other VS Code extensions will assume they are present and may depend on them
  • VS Code built-in extensions: when to use them in main repo?
  • Main repo language extensions / example applications: as previously discussed, we want to only keep TypeScript, moving or discarding other language extensions. The example apps can still be used for "self-hosting" -> developing Theia in Theia.
    • Ericsson plans to soon move @theia/cpp to eclipse-theia/theia-cpp-extensions repo and remove cpp support from examples apps
    • The Java extensions can be discarded from the repo and example apps; those who need Java can use the VS Code extensions instead. theia-ide/theia-apps examples applications can eventually be updated to use Java VS Code extensions
    • @theia/python can probably be discarded, removed from example apps, as well
    • Mitigation: we can consider keeping the to-be-discarded extensions and example applications for a while, maybe on a branch where they could be maintained for a while, if anyone cares to do that, or at least "looked-at"
  • Theia 1.0: Agreed upon 2020-03-26 as target date. Content:
    • APIs: go thorough our APIs, have a way to tag those we consider to be most important ones, that will be considered the public APIs, that will be tracked, subject to breakage.
      • API tooling would be a nice-to-have but can wait after 1.0
    • VS Code extensions support: already in pretty good shape. The extension registry TypeFox is working-on will be a nice addition as well.
    • Electron build(s): could start with example Electron application, need to figure-out "signing"
    • Documentation: improve extender and end-user doc: make it good looking enough so that people will want to write more, maintain what's there

Minutes, 2019-10-29

  • [CI] Force green builds for all platforms. Currently, only the Linux build is mandatory. Should we enable it for all platforms? See here for more details.
    • Windows and Mac CI is more stable than it once was. When unstable it's sometimes because we do not notice that it's broken
    • Windows and Mac may not have as many Travis executors, so possible slight delays expected before CI gives a verdict
    • No objection to give this a try- we can revert if it causes headaches. Vince to submit PR
  • SCM support via Theia vs VS Code extensions: https://github.com/eclipse-theia/theia/pull/6381#issuecomment-545389965
    • There was a limited audience present at meeting today - @westbury agreed to postpone item until next dev-meeting
  • Created 0.12.0 release on project page
    • Release tentatively scheduled for October 31st.
  • NPM dependencies security report: @vince-fugnitto created a repo in which a yarn audit is run nightly against a Theia application that contains all of our main repo's extensions. The results are then published as a report on GH pages. We plan to move this repo under the theia-ide org and use the reports as a way to find-out about the known security issues with our dependencies.
    • Note: by design we do not use the main repo's yarn.lock file since it has no effect on Theia applications other than the example apps from the main repo, and it may give a worse-than-reality picture of Theia's security
    • Florent would like a version of the audit to be run using theia's main repo yarn.lock.
      • with the intention to update main repo's dependencies following each release, using yarn.lock or not when doing audit may yield similar results in the future. Florent mentioned dependabot could be helpful to do this dependency upgrade in an automated way as a first pass.
    • created new repo for this: https://github.com/theia-ide/security-audit
  • [electron] Enabling asar packaging: would be interesting but require many Theia changes. ARM to start looking into it, Ericsson potentially interested
  • [electron] Permit Electron main to have its own inversify container, so it's easier to customize. Paul will look into this, ARM potentially interested

Agenda, 2019-10-22

  • No meeting today since most committers are at EclipseCon

Minutes, 2019-10-15

  • (Anton) improve dev compression to have better experience during Theia Workshop at EclpiseCon next week: https://github.com/eclipse-theia/theia/pull/6266
    • Anton posted this entry to reflect today's discussion on this topic
  • It was proposed to skip next week's dev-meeting since many will be at Eclipsecon. If someone want to hold the meeting, add an agenda entry and content for it.
  • The subject of the recently announced Visual Studio online . It's likely that there will be questions about that how it stacks-up vs Theia.
    • update: this seems to be part of the same announcement as the VS Code Remote extension, from May 2019. Ref discussion on Spectrum from that time for arguments why Theia is better

Minutes, 2019-10-08

  • <meeting was skipped, no topics>

Minutes, 2019-10-01

  • Sven: Added https://github.com/eclipse-theia/theia/wiki/Coding-Guidelines#imports
  • Florent: tslint rule to enforce ordered imports ? tslint-fix script ?
    • ok, but make sure everything still works afterwards
  • We're trying Zulip as a potential Spectrum replacement. For now we'll use it for "dev" things, but can switch completely if we like it. Theia org: https://theia.zulipchat.com/. To join as an org member, use this invite link .
    • We start with the free version, but should be converted to the "standard" version (free for open-source projects) by their support soon. update: got email from support that this has been done
  • Florent: refresh Theia with use of new VS Code icons ? (https://code.visualstudio.com/updates/v1_37#_new-product-icons)
    • Concern: one needs to be logged-in to read Zulip, so how will search engines be able to read/index? There might be a way to "export" topics?
    • Would slack be a good alternative? From memory some limitations may be limit # of users, no login with GH credentials, perhaps other issues as well
  • Florent: Electron 6 / https://github.com/microsoft/vscode/issues/76069
    • VS Code are still struggling with this, we should probably should let them figure it out
    • concerns: security, packaging (apparently Electron-builder works with Electron 6.x as of July)
  • Florent: nodejs 12
    • will be the next LTS. Update tied to Electron update
  • [Paul] wants to discuss his PR: yarn upgrade #6255
    • currently: consumers of Theia NPM packages are not affected by our yarn.lock. e.g. if we tweak to avoid a certain problematic version of a dependency, this will only work locally for the example apps
    • Proposal: yarn upgrade main repo dependencies every month, early in release cycle, (e.g. soon after a release)
      • can reveal subtly coding bugs in Theia
      • Paul to try after October release
  • Rob: Electron security: https://github.com/eclipse-theia/theia/issues/2018
    • ARM has report that demonstrates that this is a legit issue
    • Maybe Electron 5 fixes this? If so could be a motivation to move to this version
    • What about Electron 4?
  • VS Code icons: should we update ours to follow?
    • Alex mentions that he already has an approved CQ, so we should be able to use that version of the icons if someone wants to make a PR
    • Icons available as NPM package, so maybe we do not even need to "fork" them?
    • Monaco already uses the new icons, so we might have a mix of new and old, which will look odd
    • Vince has an issue about updating icons. Will make proposal

Minutes, 2019-09-24

  • Anton: help required to finish committer paperwork: https://github.com/eclipse-theia/theia/pull/6090#issuecomment-533951653 - resolved
  • Release entry for 0.11.0 created on Eclipse project page. ETA: Thursday September 26th.
  • Florent: I don't see anymore plug-in-ext code automatic reviewers for code owners ?
    • Need to add reviewers manually since repo move. Foundation does not have resources to manage GH Teams manually. They have plans to do such things automatically, but no ETA. Possible to help; see this bugzilla comment
  • Florent: Add VS Code like examples (examples/browser have some theia extensions that are colliding with usage of VS Code extensions so would be nice to have a reduced Theia example close to VS Code. BTW a lot of PR are saying as well: first, drop these extensions from the examples so would be nice to have a closer example)
    • this means basically to have our example applications use the built-in VS Code extensions as much as possible, instead of the equivalent Theia extensions. e.g. for textmate support, node-debug. We probably can't switch to the VS Code version of git short term, but longer term there would be benefits.

Minutes, 2019-09-17

  • Eclipse Foundation repo move
    • Repo move has happened. A few CI-related hiccups at first, but things have stabilised within a couple of days.
    • No immediate need to update remotes in local git repo: GitHub will transparently redirect to the new repo. Same for links/URLs to the repo, issues, PRs.
    • AppVeyor has been replaced by Travis, that now supports Windows. https://github.com/eclipse-theia/theia/pull/6179
    • Did a pass to change links to old org in the repo.
    • Teams: partially re-created in new eclipse-theia GH org. Many committers are not members yet - first one must accept invitation to join the org. The following committers seem to be in that situation; please look-for and accept invitation email:
      • akurinnoy
      • caseyflynn-google
      • JanKoehnlein
      • jbicker
      • RomanNikitenko
      • thegecko
      • westbury
  • Anton: https://github.com/eclipse-theia/theia/issues/6187 - a proposal that an opening a view from the main menu bar (for example View -> Explorer) should always reveal and focus, instead of toggling as for now
    • -> sounds like a good proposal. Not clear from issue if there are aspect that need to be discussed? If so maybe bring back subject next week.

Minutes, 2019-09-10

  • when to merge Monaco PR: https://github.com/theia-ide/theia/pull/5901#issuecomment-529310593
    • no objection to merging this PR
  • move away from Spectrum: https://spectrum.chat/theia/general/move-from-spectrum-to-another-community-platform~0ea70ca2-7672-4d1d-a2dd-7df2a9c984f2
    • one concern is that the new choice be indexed by google so that answers to past issues would be "discoverable"
    • chosen solution should be free (as in beer) yet full-featured or at least not too limited
    • let's continue this discussion on the Spectrum room above
  • dropping native debug extensions: https://spectrum.chat/theia/dev/dropping-native-debug-extensions~7e70a46d-08fe-4bea-a88b-bee235c124f7
    • Theia is not v1.0 yet, so we have some "leeway" to do such things with minimal/no warning
    • In this case, let's do two things first / along with removal:
      • open a GH issue where we document the removal of the extensions, including way forward and how to mitigate problems that our users will face if they include one or both in their Theia apps. e.g. to continue using the already published version of the removed extensions, on can use a resolutions block in the app's package.json to pin the versions of every Theia extension to avoid having 2 versions pulled.
      • In the PR where the extensions are removed, add the corresponding vscode extensions to the example applications, so that functionality is maintained; this can be pointed-to as an example to our users how to proceed if they want to migrate to the node-debug / java debug extensions
      • Question: in the case of Java, is there a need to keep any Java support in the form of Theia extensions? Could we use the Red Hat vscode extension instead and get rid of @theia/java and @theia/java-debug?
        • in that case, the theia-java-docker app could be updated to use the vscode extension(s) and be the example we point-to. We could then remove java completely from the main repo example applications.
  • Do not change existing keybindings in Theia. It breaks downstream projects. For instance, this commit breaks the behavior of a downstream, Theia-based application.
    • Meant as a general "warning" to the dev community. Ideally we would have a better mechanism to allow extenders to remap default keybindings. But until we do, we should be careful then
  • Eclipse Foundation repo move
    • [Ongoing] Bug 549757 - Configure GitHub applications for new eclipse-theia organization and repo theia-cpp-extensions
      • Appveyor listed in PR but does not seem to actually kick-in (status: "queued"). Webmaster reports it's not listed as a GH app after being installed. The issue could be with the the theia-cpp-extensions repo we use to test.
      • Gitpod not listed in CI section of PR, despite webmaster reporting it's installed. e.g. see here
      • Travis publishing of next still untested - the theia-cpp-extensions repo not yet in a state where publishing works, so hard to test.
    • Next step: Bug 540398 - Main Theia repo move to eclipse-theia org
      • What needs to work before the move and what can be fixed after? Appveyor, Gitpod? Any way to mitigate so we can go ahead with the move if a wanted integration is not known to work yet?
      • tentatively this week (we were asked to do so by September 15th, which is Sunday).
      • minimal disturbance expected: GH will redirect to the new repo URL automatically.
      • Minor updates, e.g. to point to new repo URL in documentation (e.g. README?) can be done after?
      • Any other concerns? Things to be done before?
        • conclusion: dev community ok with the "just do it" approach. Let's proceed wit the repo move and fix remaining issues after. [Marc] to try to schedule move with webmaster on this Thursday September 12th. No downtime is expected so no great need to notify users.
    • [update] After the remo move, can we preserve the GitHub teams that we recently created?
      • Discussion in this bugzilla
        • TL;DR our options are limited. Through Anton's tests committers seem to be able to create public teams and assign committers to them, but we can't add contributors or give them triage permission, nor is the Foundation willing to do this for us at this point.
        • Dev community momentarily ok with these limitations, after repo move. Will continue to "push" for this with the Foundation.

Minutes, 2019-09-03

  • Anton: how to reason about and test APIs without internal clients: https://github.com/theia-ide/theia/pull/6070#issuecomment-526909734
    • suggestion to have an example application in which plugins-related features could be tested
    • Plugins resources provider contribution point
      • a way to abstract where plugins resources are located, e.g. allowing them to be found remotely or generated on-the-fly
      • Not Che-specific: can in theory be useful in Theia too.
      • conclusion: for the proposed resources abstraction contribution point: generally we prefer to avoid adding abstractions for which there are not at least two solid Theia-specific use-cases. In this case it's suggested to start by adding an API but not a contribution point. This can be revisited later when the need for a contribution point is more concrete.
  • Eclipse Foundation repo move

Minutes, 2019-08-27

Minutes, 2019-08-20

  • The monaco update will not go into the next release. PR is ready to be tested.

Minutes, 2019-08-13

  • Anton: reconsider circular dependency check - https://github.com/theia-ide/theia/pull/5886#issuecomment-519882167
  • Eclipse Foundation IP process:
    • [Marc] had a meeting with Sharon and Shawn to discuss the proposal to have one CQ, for copied code, to analyse the whole code base of a version of vscode, instead of the piecemeal CQs we have so far. The concern is that the amount of CQs we generate is high, and the foundation has been prioritizing our CQs so far, but maybe can't keep-up indefinitely, resulting in eventually slower response time on their part.
    • One aspect is that if we were using that code but not modifying it, the analysis would be easier (could be type A instead of B). I mentioned that for icons and interfaces, it could be argued that we do not significantly modify the copied code, other than e.g. adding a Microsoft header to icons and copying the interfaces somewhere where it makes sense for Theia and making small adaptations to make fit in the Theia context.
    • Sharon, when back from vacation, will bring this info to her management IP meeting, where it will be discussed. She can update us after, ETA first/second week of September.
    • In the meantime, we should continue to register "piecemeal" CQs, like we have been doing so far.
    • wiki updated to reflect that the "special process" is on hold for now.

Minutes, 2019-08-06

  • Anton: pending CQs for code copied from vscode repo, see https://dev.eclipse.org/ipzilla/show_bug.cgi?id=20459#c4 and https://dev.eclipse.org/ipzilla/show_bug.cgi?id=20504#c3, some PRs cannot be merged
    • conclusion: [Marc] to go ahead and register a CQ for the whole of the latest vscode release, specifying that we want the pending CQs to still proceed. Also will update our wiki page about CQs to document the vscode version (eventually versions) that are already wholly covered, from which committers can copy code without registering an additional CQ (since already covered)
    • update: CQ created: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=20620
    • Registering_CQs wiki page updated
  • Eclipse Foundation repo move. Based on strategy proposed in last dev-meeting, opened/updated bugzilla's: Each item depends on the previous one, with the final one being the move of our main repo:
  • Marc D. on vacation for next 2 weeks. Volunteer(s) to lead dev-meetings for those weeks?
    • Sven volunteered.
  • Adding danger to enforce compliance to the pull request template.
    • [Anton] to try this or other similar pertinent GH app on the theia-ide/theia-apps repo first. If successful we can consider doing similar on main repo.
  • Using GitHub Teams instead of individuals in mentions: there are cases where it could be beneficial to abstract the individuals in GH mentions and instead use a team. We can try with one or two to begin-with and see how it goes
    • [Marc] to create a GH team for Eclipse Foundation IP stuff, to be used instead of mentioning my GH user when it's about CQ/IP related questions.
      • update: @theia-ide/ip-help team created. It can be used for tagging/mentions just like GH user names. Seems it's not yet possible to assign a team to a PR or issue
  • Theia Dev Conf 2019: Andreas From suggests that we should hold a retrospective meeting about the event (what was good, what could be improved, ...), in a few weeks once the summer vacations are generally over. As well begin discussions about next year's event. [Andreas F] to open an issue on the main repo to collect feedback about the event, for those who have something to say but will not join the meeting.
  • PR Reviews "load sharing": Discussion about how some other projects have a structured way to on-board contributors, making them feel welcome, and so increasing the odds that they'll contribute more in the future. Helping with PR reviews is one potential thing some could do, if we successfully .
    • make contributors that we think have good potential members of the org, so they have the associated "badge" in their GH profile. Can we do that, through a bugzilla, once the repo is moved under Eclipse Foundation control? It might look like a Foundation endorsement? It might be ok to just make them part of the theia-ide org even after the main repo's move.
    • [Anton] to update project's CONTRIBUTING.md file to generally encourage participation in PR reviews, validation of PRs.

Minutes, 2019-07-30

  • Anton: conventional commits: https://github.com/theia-ide/theia/pull/5616#discussion_r308229747
    • Maybe we could try this first on one of our smaller repos, like theia-ide/theia-apps. The CI in that repo is quite intense, with many Docker images to build/publish. With contentional commits, there may be an opportunity to be smart about which image(s) to run CI on, depending on which part(s) a PR touches. e.g. if a commit only touches one specific image and it's tagged in a standard way, we could be smart in the Travis config and perhaps only build/test/publish that image.
  • Anton: confusion about code-ownership: https://github.com/theia-ide/theia/pull/5791#issuecomment-514990903
  • PR Reviews: There was a discussion about having a fairer distribution of effort wr to doing PR reviews. ATM and for a while, TypeFox has arguably contributed to reviews more than their fair share, and there is a concern that Anton is becoming the default reviewer for the project. There is a tendency for committers to mostly review PRs from their own organizations and giving less attention to other PRs. For the good of the project, we should work to improve this.
    • suggestion: create a GH team for reviews, where volunteers among the committers, willing to invest e.g. at least 2h a week, could be added. Then we could assign incoming PRs to the team.
    • (another idea post-meeting) could we take advantage of non-committers as well? The review of a non-committer is not enough to approve a PR, but the feedback could still be valuable, and could be a good way for someone to build-up "cred" in the project, and eventually become a committer?
  • Eclipse Foundation repo move:
    • we requested webmaster create new eclipse-theia GitHub organization, to hosts Theia-related repos. Some services, like Travis CI, share resources at the org level, so not having to share with the ~600 projects under the eclipse org will help.
    • next step: move some of our existing repos, from the eclipse org to our new one. e.g. eclipse/theia-cpp-extension
    • with help from webmaster, install/configure needed GH apps in new org: Travis CI, Appveyor, GitPod.
      • then on the day we move the main repo, almost everything will already be ready
  • Theia 0.10.0 on track for release as part of the Foundation, end of August.

Minutes, 2019-07-23

  • Che 7: https://github.com/theia-ide/theia/pull/5772#issuecomment-514117967
    • Conclusion: ok for this time but in the future an alternative should be used instead of creating a product-specific branch in the main Theia repo (e.g. do it in a fork)
  • [stale bot] we are trying it on the theia-apps repo. See current config here
    • each repo may need a different config. In this one both issues and PRs are covered ATM
    • created a no-stale label and added it to the stale bot config. It can be used on issues/PRs, so that the bot will ignore them
    • To avoid a lot of issues being marked as stale very quickly, it's possible to start with one label, like question, and slowly add labels that the bot will handle.
    • It's important to do a follow-through by committers to make sure that issues marked as stale really are no longer needed.
  • Theia July release, 0.9.0: The Eclipse Foundation review will not be completed in time for Thursday July 25th. We can proceed with the release outside the Foundation or wait for the review, scheduled for August 7th. Is anyone eagerly waiting for 0.9.0?
    • Conclusion: we'll release 0.9.0 as scheduled this Thursday and do 0.10.0 next month as per the Foundation process, after the release review is passed.
    • Note regarding the release review: This is a punctual problem; release reviews now only need to be done once a year, so once we pass this one, as long as we maintain good compliance with IP processes, we will not need to worry about this for a while.
  • We were asked to do a few things before we are allowed to release as part of the Foundation:
    • [Done] "Grant the Eclipse Webmaster (@eclipsewebmaster) administrator privileges on the Git repository;"
    • [WDYT?] "Commit to moving the repository before September 15;"
      • No objections. Will be made easier by the offer to postpone squashing the repo's history, while the Foundation decides if this step is still required for new projects moving to the Foundation, going forward
    • [ONGOING] "Ensure that the Git Repository conforms to all Eclipse Foundation branding guidelines; and"
    • [DONE] Resubmit the IP Log.
    • See more details in this mailing list post by Wayne

Minutes, 2019-07-16

  • [stale bot]: ready to try it on the theia-apps repo: committed the config file for probot stale, just need to install the integration on the org and enable on this specific repo. Objections? If it works well, we can consider if we want to enable the integration on our main repo.
  • The videos for TheiaDevCon 2019 talks are now available on the Eclipse Theia youtube channel
  • Theia July release, 0.9.0: will attempt to do it under the Eclipse Foundation. Additions to the release documentation are welcome. Took inspiration from what's in CHANGELOG.md for the content of the release, but there was not much in there.
  • AOB

Minutes, 2019-07-09

  • [proposal]: It would be nice to have a stale bot for the GH issues with the question label; I always feel uncomfortable when to close them. There is already a task for it. (@kittaakos)
    • There were some concerns about using such a bot. e.g. we have some old issues that are still valid, and we do not want to have to comment on them frequently to keep them "alive". Also if such a bot was misbehaved or misconfigured, it could potentially close hundreds of issues that should not be closed. Only enabling the bot to close "question"-type issues, as suggested by @kittaakos above, would mitigate these potential problems. Another mitigation, suggested by Anton, would be to have a relative long delay before closing an issue, like 6 months or 1 year.
    • Vince will try the bot above on his Theia repo fork and report-back his observations
  • A committer election for Yukun Wang is ongoing. Current committers can check their email for the Eclipse Foundation notification for this election.
  • Radim Hopp (Red Hat QE lead for Eclipse Che) will present the efforts going on at Red Hat towards a UI/e2e test suite for Che, which includes Theia. What they are doing, lessons learned, etc.
    • slides here
    • [takeaway] it seems Cypress would not help us much vs current wdio test suite.
    • [takeaway] integration tests should cover basic scenarios, leaving exhaustive tests at the unit level
  • Paul's suggestion to do integration tests at the Theia API level: Anton has a WIP/PoC PR: frontend api tests to play with the idea. Paul had a quick look and will go deeper once back from vacation in ~1 week.

Minutes, 2019-07-02

  • Anton: ideas to improve PR review? https://github.com/theia-ide/theia/pull/5616
  • Eclipse IP / Move:
    • VS Code built-in extensions CQ ( #19512) is officially approved (license_certified).
    • next step: do the July release as per the Eclipse Foundation process
  • Current UI / Integration test suite, based on WDIO: what's the status of the potential replacement, based on Cypress, that is/was being looked-into by Red Hat?

Minutes, 2019-06-25

  • Eclipse IP / Move:
    • VS Code built-in extensions CQ: git extension's usage of LGPL-licensed jschardet: Gorkem presented the case to the last Eclipse Board Meeting, and it was approved (license_certified). So it should now be possible to have CQ#19512 approved as well, covering usage of VS Code build-in extensions by our project as well as Che's and other Eclipse Foundation projects. For more details, here's the jschardet CQ#20251
    • Theia main CQ #16798: the few remaining requests from Sharon have been done. Status: approved.\
  • Theia 0.8.0 release tentatively on June 27th. Anything that should be included?
    • "fix the workspace pref not being applied on change", see #5498 : can someone review?
  • yarn.lock:
    • Somewhat of an opinionated matter, but should we either remove the lock file, and/or add tests not using it?
    • Motives:
      • Lock files are only effective inside our main repo, it has no authority over dependents.
      • When doing a CQ for a dependency pinned in our lock file, dependents may pull something else.
      • Lock files ensure that our CI is not failing, but why do we have a CI in the first place? Answer: To catch issues. What good is it if our repository is fine but dependents not?
      • Lock files are good when making an application/product, but when working on libraries (software meant for reuse) some communities recommend not using it (e.g. Python).
    • should be discussed more widely before taking a decision to change the current setup

Minutes, 2019-06-18

  • Anton: get rid of Sinon see https://github.com/theia-ide/theia/issues/5429
    • There have been issues with Sinon tests because they mock internal APIs and end-up failing if the corresponding implementation changes.
    • Avoid using Simon for new tests, limit use to public APIs.
  • Rob: v1.0 roadmap
    • Features / owners
    • Tracking using projects / issues
      • should break-down big topics to increase chances that someone will commit to them Documentation
      • need a mix of documenting APIs in the code with JSDoc and higher-level documents like guides
      • a blog is in the works for the Theia web site, as part of the update, ETA end of August
      • Rob had a very good list of "often asked questions" related to missing documentation
  • Eclipse IP / Move: no progress this week, Marc busy with internal tasks
  • Next week's meeting
    • There is a Che face-to-face, so attendance from Red Hat could be low
    • Anton on Vacation next week
    • Montreal contributors are off on June 24th and July 1st

Minutes, 2019-06-11

  • QA for PRs:
    • more focus on "testing before merging". Automated tests do not help that much for new features.
    • for submission of "core" contributions, e.g. that affect architecture, please make sure to involve the right people and only merge after they give the "OK".
    • in the future, if a PR causes serious issues after merge, we have the option of reverting the commit(s) and ask the submitter to work on it some more, fix issues. It's suggested that a if it takes more than 2 days of work to fix, or if submitter can't work on it right away, reverting would be a good option.
    • Maybe the Red Hat QA team could help as well with PR testing?
  • We have 3 new commiters: Igor Vinokur, Oleksii Kurinnyi and Roman Nikitenko.
  • [git] Anton is working on a PR, aiming to fix ~10 git issues: rework scm, recover git extension. Will need community help to review/test.
  • Eclipse IP / Move:
    • libffmpeg proprietary codecs: need to wrap-up a few things at Board request CQ #19939
    • Git VS Code built-in extension LGPL dependency: Sharon suggests we can go ahead and ask the Eclipse Board for an exception. Will need to open a CQ for the dependency (jschardet) and provide justifications.
      • "Regarding jschardet, we have confirmed VS Code has a strong and unavoidable requirement for the jschardet dependency." - I think someone was looking-into replacing jschardet: should we instead do as Sharon suggests and and ask for an exception? Too late for June, so we can aim for July.
  • TheiaDevCon: quick impressions?
    • overall positive comments from committers that attended. Surprising good turnout, with diversity of companies, specially when taking into account that we were late in organizing the event and that there was almost no marketing or publicity done.
  • Theia 1.0
    • Rob will create a wiki where we can document what we would each want done before "1.0".
    • We will be looking for ideas but as well for people/companies to commit to doing some part of that work.
    • The move to the Eclipse Foundation is one such prerequisite, mentioned at TheiaDevCon. Looks good to complete it this summer.
  • The call for papers for eclipsecon Europe 2019 is open until July 15th. Early bird starts on July 1st.

Minutes, 2019-06-04

  • no meeting today, as a large portion of contributors are at TheiaDevCon.

Minutes, 2019-05-28

  • Eclipse IP / Move:
    • Electron proprietary codec in libffmpeg issue: The measures we have taken to make sure we do not distribute the version of libffmpeg that has proprietary codecs have been presented to the Eclipse Board. I understand that they accepted our library replacement strategy. I was asked by Sharon to open a new CQ for this and describe what we have done. Here it is: CQ #19939
    • Akos and Alex are helping close the couple of remaining small IP issues, from our main/initial Theia CQ.
    • along with resolving the libffmpeg problem, it's looking good to finalize the move to the Eclipse Foundation in time for next month's release, baring new surprises.
  • Electron long startup time: we (Ericsson) have noticed that Theia Electron applications take longer to start vs browser applications. We would like to improve on that. See the following issue where we can discuss this: #5284

Minutes, 2019-05-21

  • Welcome to newly elected committer Thomas Mäder!
  • Eclipse IP / Move:
    • [Electron] proprietary codecs in libffmpeg: we have provided the details to the Eclipse Foundation Board, of our proposed solution to avoid distributing the version of libffmpeg that has proprietary codecs. IIUC this will be presented at the May Board meeting (this week?).
  • Release of Theia 0.7.0 tentatively scheduled for Thursday next week (May 30th).

Minutes, 2019-05-14

  • New committer nominations coming soon from Red Hat (Thomas, ...)
  • (Ericsson) a new coop student joined our Theia team for the summer (at least): Naxin. He has started to ramp-up and work on a few PRs
  • Bugfix release 0.6.1 published last week, containing this fix, on top of 0.6.0. The fix is also in master, and will be automatically included in 0.7.0.
  • Eclipse IP / Move:
    • Electron proprietary codec in libffmpeg issue: With Gorkem's help, we will present to the Eclipse Board our solution to exclude the version of libffmpeg that contains proprietary codecs, in development and in eventual application packagings.
    • Next IP issue to tackle: LGPL-licensed library pulled as dependency by built-in VS Code git extension: CQ 19512. Shall we ask the Eclipse Board for an exception? Can we live without this extension and keep using Theia's version?

Minutes, 2019-05-07

Minutes, 2019-04-30

  • Code Freeze (topic suggested by Anton)
    • we do not have a pre-release code-freeze ATM, though individual committers can use their judgement as to whether it's risky to merge a given patch shortly before a release, and if so decide to postpone until the release is done.
  • 0.6.0 release: later today, afternoon Montreal time.
    • We wanted to release using the Eclipse process, but will not be able-to this month - see below.
  • Eclipse IP / Move:
    • Electron IP clearing: our recent switch to Electron 3.x has triggered an investigation by the Eclipse board. They asked for some re-assurances that the Electron-bundled libffmpeg shared/dynamic library does not contain proprietary codecs, subject to patents. We were asked to help making that determination as well as to help find a way to test for this in the future.
    • We have been able to confirm that libffmpeg does indeed contain such proprietary codecs, such as H.264. This is also true for Electron 2.x, so going back would not help.
    • The Electron project has been asked about this in the past. They do provide a download for a standalone libffmpeg in which the proprietary codecs are not present. But so far no obvious way to replace the default version of the library with the wanted one.
    • Until this is addressed, Theia can't be "IP certified" and so we can't technically release, under the Foundation.
    • After discussion with Sharon and Wayne, we can for this month, release like we had been doing so far, outside the Foundation. In the meantime the investigation continues.
    • This needs to be fixed somehow, before we move the repo, or we risk not being able to release.

Minutes, 2019-04-23

  • 0.6.0 release: I (Marc) started with the paperwork too late for our usual "last Thursday of the month" release. Aiming for Tuesday April 30th instead, though I had to set May 1st as the official date for the tool to accept (1 week hardcoded period for release reviews).
    • Bugzilla to track the release: here
  • Eclipse IP / Move:
    • CQ #19512, about confirming license compatibility for our built-in VS Code extensions: I received no feedback from Red Hat about the preferred way forward. Technically this CQ does not need to be resolved immediately or before the monthly release since this content is not yet used. We can put it on ice until it's needed by someone.
    • Reminder: New or updated 3rd party production dependencies: we no longer need CQs for most cases, but there is still an analysis to be done. Please ping me (@marcdumais-work) in the PR and wait for feedback before merging (should not delay for long vs a CQ).

Minutes, 2019-04-16

  • Eclipse IP / Move:
    • New development about CQ #19512, about confirming license compatibility for our built-in VS Code extensions: we noticed an LGPL-licensed library is used as a dev-dependency by the built-in git VS Code extension. So this CQ back to being under analysis. More related info here and below.
      • We do not, at this time, reference these built-in extensions from the Theia repo, so this does not yet affect our project. However it will affects Che and potentially other projects under the Foundation, that will need the built-in extensions to be license_certified before they are allowed to use them. So it would be good to have someone from Red Hat be involved as well.
    • new Foundation-proposed process for License Certification of production dependencies: I (Marc) had a hands-on session with Sharon about using the ClearlyDefined web tool to do our own License Certification. It's relatively quick and painless, and in case of doubt we can ask for help.
      • The idea is that we would use this tool, whenever we have a new or updated production dependency, to try and catch suspicious licenses being pulled-in. One week before a release, we would fill-in the Foundation's "paperwork" and they would also check for anything we missed.
      • Hopefully they have time to finish their checks before the release date, but if not we can still proceed, but with the (small, managed) risk of needing to take action if we missed something.
      • I think it would be good to have a volunteer or two, from the group of committers, that can ramp-up about this tool/process, with my help, so that I do not become the bottleneck. Maybe Florent would be a good candidate?
        • Florent and Sven volunteered!
    • The move of our main repo to an Eclipse-Foundation controlled GH Org: was briefly discussed with Sharon and Wayne. We can go ahead when we want, but we should give a bit of a heads-up to the repo's users, that will need to take action after the move (new repo with all new SHAs). We should also confirm before that we are satisfied that the new License Certification process is good/light enough not to be an huge impediment. Shall we go ahead? Maybe "soak" the new process for this month first?
      • no objection to the plan to try the new "self-license-certification" process for a month or so and schedule the move soon after the May release.
      • Q: why do we need to collapse the repo's history when moving to the Foundation? A: (Marc's interpretation) The Foundation analysed our repo at a specific point (tag: eclipse_initial). There might be some unwanted content/licenses before that point and so it would be a risk to keep that history. The "collapse" will affect the commits from the initial one in the repo up-until the commit with eclipse_initial tag: all of these will be squashed into a single commit. Every commit after that point will be kept but will change SHA.
      • more details here and here

Minutes, 2019-04-09

note: the meeting is now at 2PM UTC

Minutes, 2019-04-02

  • Meeting time: We propose to switch to 2PM UTC starting next week, until October/November when we switch back to "normal time".
  • Announced the Call for content for the upcoming Theia Developer Conference
  • Eclipse Foundation move / IP: We received the Eclipse Foundation proposal to lower our project's time spent on registering CQs for production NPM dependencies: "ECD Theia Intellectual Property Clearance Approach (Experimental)".
    • In short is seems to suggest that we would analyse new/updated 3rd party dependencies ourselves, using suggested tools and the Foundation's acceptable licenses white-list.
    • CQs for things other than 3rd party dependencies are un-affected. i.e. Still need CQs for e.g. external contribution >= 1000 LoC, for copied code from another project, ...
    • I am giving the suggested tools a try; will report back and update our related wiki page.
  • CQs for built-in VS Code extensions? (Anton, Florent, Thomas). Issue
    • Thomas confirms this is time-critical for Red Hat; CQs can take a while to sort-out, so it would be better not to wait too much
  • ...

Minutes, 2019-03-26

note: Until the end of the month, the meetings will be 1h later than usual in North America (we went to daylight saving before Europe).

  • Anton: simplify API docs generation
  • Anton: not clear how to CQ prod dependencies, see https://github.com/theia-ide/theia/pull/4680#issuecomment-476174121
  • Eclipse Foundation move / IP:
    • Electron CQ #19253: license_certified! As we had noticed, Electron was already granted an exception by the Eclipse Foundation board a while ago, which is now extended to Theia as well.
    • NPM production dependencies CQ #18717: Progressing. A few more false-positives were found; responded this morning. Hopefully on the verge of being license_certified.
  • Next release on Thursday, March 28th.

Minutes, 2019-03-19

note: Until the end of the month, the meetings will be 1h later than usual in North America (we went to daylight saving before Europe).

  • Eclipse Foundation move / IP:
    • Electron LGPL content: We were asked to create a separate CQ for Electron and provide some basic information about its usefulness in Theia. We will go forward to ask the Eclipse Foundation board to approve our continuying usage of Electron. See: spectrum discussion and new CQ
    • CQs recently approved: 18523, 18336

Minutes, 2019-03-12

note: from this week until the end of the month, the meetings will be 1h later than usual in North America (we went to daylight saving time last weekend).

  • Eclipse Foundation move / IP:
    • new issue with NPM production dependencies CQ: some LGPL content is downloaded by the electron package during post-install. We will ask the board for an exception, if necessary, so we can continue to use Electron. More details on spectrum
    • a few of our pending CQs were recently approved: 18334, , 18337, 18454, 18832

Minutes, 2019-03-05

  • Eclipse Foundation move / IP:
    • Latest news from Sharon about "NPM Technology and IP Clearance": How can we handle IP Requests in the ever changing NPM world in order to ensure license compliance while Eclipse projects can continue to develop? @Gorkem Ercan we do have something in mind which is very similar to what you have suggested! More to come on this soon.
      • for reference, here is Gorkem's suggestion: would it be possible for us to submit a single update for the dependency version updates periodically for instance quarterly? And submit CQ for new dependencies only.
    • "pilot" about using package-lock.json when opening npm production dependencies CQs: we are trying tool synp to translate yarn.lock to package-lock.json. Submitted a couple of such translated files for 2 of our repos. Waiting for Foundation analysis. If deemed successful, we would no longer need to attach the zip containing our node_modules folder and could instead attach package-lock.json.
  • ...

Minutes, 2019-02-26

  • 0.4.0 release this Thursday, with some breaking changes. See CHANGELOG.md for more details.
  • Eclipse Foundation move: NPM CQ is unblocked, now that the GPL-licensed dependency was removed (thanks Akos). CQ still being analysed.
  • What's going-on with the Theia Developers Conference? No recent updates on spectrum

Minutes, 2019-02-19

Minutes, 2019-02-12

  • Migration to VS Code built-in extension: Che would like to have separately downloadable components for extensions with installable prerequisites.
  • Rob: Move to Electron 3.0
  • Rob: dugite embedded git licence concerns
  • Eclipse Foundation move / IP process: Not much news. Latest: "we want to be able to provide a solution for Node/Electron/NPM and agile development and we are currently investigating a variety of solutions".

Agenda, 2019-02-05

  • Reminder for all committers and contributors: if not already done, sign the updated ECA. Go to your Eclipse profile, then to the "Eclipse Contributor Agreement" tab. Heads-up: we will need to watch-out, during code reviews, for expired ECA from committers and frequent contributors. (From memory, I think the deadline to re-sign the ECA is March 1st 2019 - since I have re-signed, the date is no longer displayed)
  • Eclipse Foundation move / CQ handling:
    • Eclipse Foundation has nothing to share yet, about their reflection on streamlining the IP process, for projects such as Theia.
    • Our latest "npm production dependencies CQ" is currently blocked in analysis because some GPL-license files were detected by the Foundation's scanning tool, in a dependency of one of Theia's production dependency. It turns-out that the GPL-licensed files are part of a git bundle, downloaded in post-install step for the dugite npm module. In this case we do not think that this bundling constitutes "linking" in the GPL sense, so there is no apparent risk of "GPL contagion" to the Theia code. However we do distribute this git bundle, since it's a automatic/mandatory download for users of our git extension. According to the info we have, any distribution of GPL-licensed content requires board approval, which could take a while. Alternatively we can make it so we do not distribute this GPL content.
  • Nominated Vincent Fugnitto as a committer

Minutes, 2019-01-29

  • Florent: code formatting rules (enforcer ?) Many PR have slight changes around code format, like spaces around brackets, on imports, etc and many users are changing it so it is creating unwanted code changes on PR (option to be hidden but changes are still there). Could we use some code formatter at build time to make code consistent across all people / editors ?

  • Eclipse Foundation move / CQ handling:

    • No news yet from the Foundation about a way forward.
    • CQ #18717: Opened 2 weeks ago. Had to be updated a couple of times following more NPM dependency changes. Multiple PRs now waiting for this CQ's approval before they can be "legally" merged. Gorkem and Marc have followed-up with Foundation.

  • Florent: @vince-fugnitto committer election ?

Minutes, 2019-01-22

  • Anton: automated end-to-end testing, how? when?
  • Anton: documenting URI usage, in coding guidelines? docs?
  • 0.3.19 release today? Everything good for ARM?
  • Eclipse Foundation move / CQ handling
    • I had the meeting last week with Sharon and Wayne of the Eclipse Foundation to discuss the way forward. They clarified one important aspect: contrary to our latest theory, publishing "latest" to NPM, as we currently do monthly, does count as an Eclipse release, with everything this entails, IP-wise. Our "next" builds can fall under the "nightly and integration builds" exception, and so would not require IP certification. However no Eclipse project is allowed to consume such non-official builds. So IIUC, once we move the repo, we will need to be IP certified before we can do the monthly releases.
    • About the way forward, on how to handle our new/updated production NPM dependencies: Sharon and Wayne asked some questions related to our project, to try to understand the challenges we face in this area. They will take this information to drive internal discussions, and to come-back with a proposed way forward, ETA beginning of next this week (has not happened yet).
    • In the meantime: I suggest that we follow the current suggested process as best we can. This will help show its limitations. The bottleneck is our production NPM dependencies, that we were told requires an "overall" CQ for any change (add new dep, new version of existing dep), in which we attach the whole set of such dependencies and their own recursive dependencies, so they can be analysed as a whole. We should wait for the CQ to be approved or to be given "check-in" permission at least, before merging.
  • Longstanding nsfw memory leak has been fixed upstream. When there's a new release, we should pick it up ASAP.
  • ...

Agenda, 2019-01-15

  • Eclipse Foundation Move / IP issues:
    • Discussion started with Gunnar, to confirm our npm prerequisite dependencies are correctly identified. Update: We confirmed that our production npm dependencies are "prereq", according to the Eclipse Foundation definition. With that confirmed, the Foundation has discussed about adapting their process to make it easier for project like ours to respect the IP process. A meeting is scheduled later today so we can learn about the proposed changes.
    • I will register a new CQ to cover all our npm production dependencies, as they are today (the previous one was from ~6 months ago and many things have changed). Assuming we can find an efficient way to keep these dependencies up-to-date as they evolve, CQ-wise, we should be good-to-go.
    • See this PR comment for more details
  • Anton: usage Logger over console in Theia repo - motivated by https://github.com/theia-ide/theia/pull/4049#discussion_r247438908
    • Add a logging namespace to be imported, basically doing the same thing as the console namespace. This avoids the DI overhead, we just need to import it. Add a tslint rule printing warnings when console is used (to allow people building with debug traces that should be removed?)
  • Anton: Should we update major version for breaking changes? - https://github.com/theia-ide/theia/issues/4034#issuecomment-454099723
    • will discuss this in the linked issue
  • Anton: When prefixing properties with _ is allowed?
  • Rob: Theia release next week pending debug fixes?
    • We plan do the monthly release a bit early this month, tentatively on Jan 22nd. Will sync-up on spectrum to coordinate.

Agenda, 2019-01-08

  • no meeting held

Project Management

Documentation

Clone this wiki locally