Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add 2019-10-10 meeting notes (closes #149)
- Loading branch information
Showing
1 changed file
with
78 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,78 @@ | ||
| # 2019-October-10 ESLint TSC Meeting Notes | ||
|
|
||
| ## Transcript | ||
|
|
||
| https://gitter.im/eslint/tsc-meetings/archives/2019/10/10 | ||
|
|
||
| ## Attending | ||
|
|
||
| * Brandon Mills (@btmills) - TSC | ||
| * Toru Nagashima (@mysticatea) - TSC | ||
| * Ilya Volodin (@ilyavolodin) - TSC | ||
| * Kevin Partington (@platinumazure) - TSC | ||
|
|
||
| Additionally, the following individuals are not in attendance but support consensus: | ||
|
|
||
| * Nicholas C. Zakas (@nzakas) - TSC | ||
| * Gyandeep Singh (@gyandeeps) - TSC | ||
|
|
||
| ## Topics | ||
|
|
||
| ### [require-atomic-updates false positive](https://github.com/eslint/eslint/issues/11899) | ||
|
|
||
| * **TSC Summary**: `require-atomic-updates` is currently on in `eslint:recommended` and appears to be flagging safe code (see examples in comments above). | ||
| * **TSC Question**: Can we remove this rule from `eslint:recommended` while we decide how we want to move forward with the rule? This should be fine to do in a semver-minor release because it will result in fewer errors being reported. | ||
| * @platinumazure points out that currently our [semantic versioning policy](https://github.com/eslint/eslint#semantic-versioning-policy) states that changes to `eslint:recommended` are semver-major. | ||
| * When that policy was written, it plausibly had in mind adding new rules and changing configurations that would make `eslint:recommended` more strict. This change, if accepted, would make `eslint:recommended` less strict. We could update the policy so that changes that relax `eslint:recommended` could be semver-minor or -patch. | ||
| * @platinumazure, @btmills, @ilyavolodin, and @mysticatea are all in favor of making `eslint:recommended` relaxations semver-minor. | ||
| * :+1: to changing the versioning policy and removing `require-atomic-updates` from `eslint:recommended` from @mysticatea, @btmills, @platinumazure, and @ilyavolodin. | ||
|
|
||
| **Resolution**: Update the semantic versioning policy to allow relaxing `eslint:recommended` in a semver-minor release and remove `require-atomic-updates` from `eslint:recommended`. | ||
|
|
||
| ### [Release schedule](https://github.com/eslint/tsc-meetings/issues/149#issuecomment-530990434) | ||
|
|
||
| * **TSC Description**: We have only 5 people active members of TSC currently, and we've lately been having a lot of trouble with finding available people to do releases every two weeks. We skipped number of releases in the summer due to the lack of availability. I propose that we either have to switch back to requiring only one person to do a release, or increase time between releases to once a month. | ||
| * **TSC Question**: Should we accept this proposal. And if so, which one? | ||
| * @platinumazure and @ilyavolodin prefer having two developers available for a release to check each other's work and debug together if something breaks. | ||
| * @platinumazure suggests single-developer releases might be easier if we merged more PRs in between releases rather than immediately before. However, we lack a way to enforce that. | ||
| * @mysticatea prefers not to reduce release frequency because that could increase the number of PRs the release participants need to review. Releases can already take 1.5-3 hours. | ||
| * @platinumazure suggests somehow timeboxing releases. | ||
| * @mysticatea suggests canary builds that are released each time we merge to master as a way of reducing load on the release team. @btmills points out that people don't often use betas and release candidates of major versions. @platinumazure points out that those require migration work, whereas canaries wouldn't. | ||
| * @ilyavolodin suggests using TSC meeting time to review PRs as a group. | ||
| * :+1: to trying a 4-week release cycle and reviewing PRs during biweekly TSC meetings until the end of the year from @ilyavolodin, @btmills, @platinumazure. @mysticatea wants to include canaries if we move to a 4-week release cycle. | ||
| * No opposition to canary releases. | ||
| * @platinumazure notes that we will need to update the bot and README for the 4-week release cycle. | ||
|
|
||
| **Resolution**: Until the end of the year, trial a 4-week release cycle and using TSC meetings to review PRs between releases. Add canary releases automatically after merging to master. | ||
|
|
||
| ### [ESLint v7 schedule](https://github.com/eslint/tsc-meetings/issues/149#issuecomment-538721777) | ||
|
|
||
| **TSC Description**: | ||
|
|
||
| Let's discuss to schedule for the ESLint `7.0.0` release. I have a rough draft: | ||
|
|
||
| - 2019-11-08 ... Start to discuss we should include what changes into `7.0.0`. | ||
| - 2019-12-05 ... Feature-freeze. After this release cycle, start to merge breaking change PRs. | ||
| - 2020-01-31 ... Stable release. | ||
|
|
||
| The following items are the reason I'm thinking it's good timing: | ||
|
|
||
| - In December 2019, Node.js 8.x will be EOL (https://github.com/nodejs/Release#release-schedule). We can drop supports for that then start to use async iteration ([RFC40](https://github.com/eslint/rfcs/pull/40) may use async iteration). | ||
| - We have a ton of issues/PRs that are breaking changes (https://github.com/eslint/eslint/projects/6) | ||
| - The `1.0.0` release was 31 July 2015 and the `1.10.3` release was 1 December 2015. Since the `6.0.0` release was 21 June 2019, so the `6.x` duration in the draft plan is longer than the `1.x` duration (and the `2.x` duration also). Therefore, from the precedent, we have enough intervals for the new major release. | ||
|
|
||
| **TSC Question**: | ||
|
|
||
| How should we schedule to release ESLint `7.0.0`? | ||
|
|
||
| * We have no reason to rush, but there's also plenty of changes to justify beginning work on v7. As long as we wait for Node 8.x EOL, anytime after that works. | ||
| * @btmills proposes following the schedule as suggested above and letting it slip if we miss a TSC meeting or release. | ||
| * :+1: from @platinumazure, @ilyavolodin, @mysticatea | ||
|
|
||
| **Resolution**: The proposal is accepted. | ||
|
|
||
| ### [Scheduled release for October 11th, 2019](https://github.com/eslint/eslint/issues/12362) | ||
|
|
||
| * Nobody is available concurrently, so @btmills proposes starting 4-week release cycles by skipping this weekend's release and reviewing PR's in the next TSC meeting. :+1: from @ilyavolodin, @platinumazure, @mysticatea. | ||
|
|
||
| **Resolution**: We will not do a release on October 11th. We will review PRs in the TSC meeting on October 24th and do the next release on October 25th. |