Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Kevin Partington
    @platinumazure
    Do we want to release? If we want to maintain the 4 week cycle, we can close eslint/eslint#12603 and let the bot generate a new release issue
    Kai Cataldo
    @kaicataldo
    Should we go ahead and close the release issue?
    Kevin Partington
    @platinumazure
    :+1: to close the release issue
    Brandon Mills
    @btmills
    :+1: to closing
    Kai Cataldo
    @kaicataldo
    :+1:
    Toru Nagashima
    @mysticatea
    :+1:
    Kai Cataldo
    @kaicataldo
    Okay, great! I think we're done then (unless we want to continue disucssing the LinterShell RFC)
    Toru Nagashima
    @mysticatea
    Thank you!
    Kai Cataldo
    @kaicataldo
    I know I personally need to give it another thorough read in its current iteration before I can feel like I have a really informed opinion
    Brandon Mills
    @btmills
    I also need to read through again
    I'll finish up the notes and then get to that
    Kevin Partington
    @platinumazure
    I'll give my thoughts in the RFC itself (I'm reading it now)
    Kai Cataldo
    @kaicataldo
    Okay, sounds good. Thanks everyone. Have a great rest of the week :wave:
    Brandon Mills
    @btmills
    :wave: thanks!
    Kai Cataldo
    @kaicataldo
    Bye!
    Kevin Partington
    @platinumazure
    :wave: Thanks everyone!
    Brandon Mills
    @btmills
    Meeting notes PR: eslint/tsc-meetings#157
    Brandon Mills
    @btmills
    :wave:
    Toru Nagashima
    @mysticatea
    Hello
    Kai Cataldo
    @kaicataldo
    :wave:
    Kevin Partington
    @platinumazure
    :wave:
    Kai Cataldo
    @kaicataldo
    I think we've reached quorum?
    Kevin Partington
    @platinumazure
    :+1:
    Who wants to facilitate?
    Kai Cataldo
    @kaicataldo
    I can!
    Kevin Partington
    @platinumazure
    @btmills Want to take notes?
    Brandon Mills
    @btmills
    I'll take notes
    Kai Cataldo
    @kaicataldo
    Looks like we have a short meeting today!
    First issue:
    Brandon Mills
    @btmills
    @platinumazure or @mysticatea will one of you respond on issues with our decisions?
    Kevin Partington
    @platinumazure
    Is today a TSC business meeting or a "review issues/PRs" meeting? (Or, given how short the agenda is, should we do both?)
    :wave: I will respond on issues
    Kai Cataldo
    @kaicataldo
    I'm up for that - how does everyone else feel?
    Brandon Mills
    @btmills
    Let's do it
    Kai Cataldo
    @kaicataldo
    Okay :+1:
    Kevin Partington
    @platinumazure
    :+1: Works for me
    Kai Cataldo
    @kaicataldo

    So for the above issue:

    TSC Summary:

    This is a follow-up from a TSC discussion on 2019/12/05 about whether configuration-related warnings could ever be added in a semver-minor release.

    I would like to allow us more flexibility on adding warnings for configuration or UX issues as semver-minor changes. Long-term, we need to be able to do this without having any impact on the exit code for the ESLint process.

    More background can be found in the initial issue post. Also, this is currently blocking eslint/rfcs#34.

    Long-term, we should probably fix this by creating a new location in the lint result object for lint run-level issues (e.g., configuration issues). Short-term, I would like to ask the TSC to consider allowing exceptions to the semver rules, on a case-by-case basis, for specific proposals in which the value of adding warnings is high enough to potentially justify breaking the users' build on semver-minor releases (especially if ESLint is already currently not working for the use case in question and we want to improve the UX and help users fix their issue). The process would be to nominate the issue on the TSC Agenda and ask the TSC to decide if the proposal should be accepted while adding warnings on a semver-minor release.

    This process change would be captured in the Maintainer Guide.

    TSC Question:

    Should we adopt a policy to allow, on a case-by-case basis, TSC discussion on issues that add warnings and whether they could be allowed in a semver-minor release?

    A follow up question I have: How do you foresee we'll move to a long-term solution?
    Kevin Partington
    @platinumazure

    I'll go ahead and note that, for RFC 34 itself, I'm thinking the whole thing is becoming more trouble than it's worth and I'd rather encourage a new CLI option or a new tool in order to let people check for potential wrong comments.

    I'm still :+1: to a TSC policy change for deciding to allow more warnings on semver-minor releases in specific cases.

    @kaicataldo Quoting from the initial post of that issue:

    • Long-term approach: Augment the lint result object to contain a top-level property for general lint run issues (including, but not limited to, configuration issues). This would contain warnings and errors arrays. Any errors in this object would result in exit code being nonzero (same as file-level errors, including rule errors). However, any warnings in this object would not result in exit code being nonzero. --max-warnings would not look at the warnings in this object-- it would only look at file-level warnings (ideally just rule warnings).

    I would want to develop that more fully in an RFC, of course, but that's the general idea.

    Kai Cataldo
    @kaicataldo
    So we would audit the existing logs and decide what goes in that property when the feature is added?
    Kevin Partington
    @platinumazure
    It might not be exactly like that actually. Let's just say the general idea is, augment the results object to support a new location for this type of warning
    Oh. Yes
    Kai Cataldo
    @kaicataldo
    Got it :+1:
    Kevin Partington
    @platinumazure
    I mean, I think we would flesh that out in the RFC
    Kai Cataldo
    @kaicataldo
    Right
    I'm not against accepting the policy listed above
    Kevin Partington
    @platinumazure
    If you prefer, the TSC proposal might be stated as:
    1. Agree to modify the maintainer guide to document a short-term policy change, per the TSC summary
    2. Soft-commit to getting an RFC in the pipeline for handling this long term
    Kai Cataldo
    @kaicataldo
    I think @mysticatea had an idea for a more formal definition of what kinds of warnings would be affected by this