mirror of https://github.com/apache/druid.git
Add more exempt tags for stalebot; Make stalebot to close PRs/issues in 28 days rather than in 7/14 days (#8084)
* Add more exempt tags for stalebot; Make stalebot to close PRs/issues in 21 days rather than in 7/14 days * Exempt labels only for issues, not PRs; Add 'Uncategorized problem report' tag
This commit is contained in:
parent
ceb969903f
commit
2d6d1c17a0
|
@ -2,6 +2,7 @@
|
|||
name: Problem Report
|
||||
about: A template for Druid problem reports
|
||||
title: ""
|
||||
labels: Uncategorized problem report
|
||||
assignees: ''
|
||||
|
||||
---
|
||||
|
|
|
@ -15,12 +15,6 @@
|
|||
|
||||
# Configuration for probot-stale - https://github.com/probot/stale
|
||||
|
||||
# Issues or Pull Requests with these labels will never be considered stale. Set to `[]` to disable
|
||||
exemptLabels:
|
||||
- Security
|
||||
- Bug
|
||||
- Proposal
|
||||
|
||||
exemptMilestones: true
|
||||
exemptProjects: true
|
||||
exemptAssignees: true
|
||||
|
@ -31,10 +25,10 @@ staleLabel: stale
|
|||
# Configuration settings that are specific to just 'issues' or 'pulls':
|
||||
pulls:
|
||||
daysUntilStale: 60
|
||||
daysUntilClose: 7
|
||||
daysUntilClose: 28
|
||||
markComment: >
|
||||
This pull request has been marked as stale due to 60 days of inactivity.
|
||||
It will be closed in 1 week if no further activity occurs. If you think
|
||||
It will be closed in 4 weeks if no further activity occurs. If you think
|
||||
that's incorrect or this pull request should instead be reviewed, please simply
|
||||
write any comment. Even if closed, you can still revive the PR at any time or
|
||||
discuss it on the dev@druid.apache.org list.
|
||||
|
@ -45,12 +39,15 @@ pulls:
|
|||
This pull request/issue has been closed due to lack of activity. If you think that
|
||||
is incorrect, or the pull request requires review, you can revive the PR at any time.
|
||||
|
||||
# Unlike for issues, there are no exempt labels for PRs, apart from "Evergreen". This is
|
||||
# to foster PR authors to complete their work.
|
||||
|
||||
issues:
|
||||
daysUntilStale: 280
|
||||
daysUntilClose: 14
|
||||
daysUntilClose: 28
|
||||
markComment: >
|
||||
This issue has been marked as stale due to 280 days of inactivity.
|
||||
It will be closed in 2 weeks if no further activity occurs. If this issue is still
|
||||
It will be closed in 4 weeks if no further activity occurs. If this issue is still
|
||||
relevant, please simply write any comment. Even if closed, you can still revive the
|
||||
issue at any time or discuss it on the dev@druid.apache.org list.
|
||||
Thank you for your contributions.
|
||||
|
@ -60,3 +57,60 @@ issues:
|
|||
This issue has been closed due to lack of activity. If you think that
|
||||
is incorrect, or the issue requires additional review, you can revive the issue at
|
||||
any time.
|
||||
|
||||
# Issues with these labels will never be considered stale.
|
||||
# There are almost all labels listed here, except:
|
||||
# Backport
|
||||
# Difficulty - *: not used these days, old issues should be revised
|
||||
# Discuss
|
||||
# duplicate
|
||||
# Feature/Change Description
|
||||
# Feature
|
||||
# Flaky test: tests tend to become less flaky in time, so these issues should be revised
|
||||
# invalid
|
||||
# Priority - *: not used these days, old issues should be revised
|
||||
# Question
|
||||
# Release Notes
|
||||
# Uncategorized problem report: they tend to decline in importance with time
|
||||
# WIP
|
||||
# wontfix
|
||||
exemptLabels:
|
||||
- Security
|
||||
- Bug
|
||||
- Proposal
|
||||
- Design Review
|
||||
- Improvement
|
||||
- Performance
|
||||
- Refactoring
|
||||
- Apache
|
||||
- Area - Automation/Static Analysis
|
||||
- Area - Batch Indexing
|
||||
- Area - Cache
|
||||
- Area - Deep Storage
|
||||
- Area - Dependencies
|
||||
- Area - Dependency Injection
|
||||
- Area - Dev
|
||||
- Area - Documentation
|
||||
- Area - Extension
|
||||
- Area - Kafka/Kinesis Indexing
|
||||
- Area - Lookups
|
||||
- Area - Metrics/Event Emitting
|
||||
- Area - Null Handling
|
||||
- Area - Operations
|
||||
- Area - Query UI
|
||||
- Area - Querying
|
||||
- Area - Router
|
||||
- Area - Segment Balancing/Coordination
|
||||
- Area - Segment Format and Ser/De
|
||||
- Area - SQL
|
||||
- Area - Testing
|
||||
- Area - Web Console
|
||||
- Area - Zookeeper/Curator
|
||||
- Compatibility
|
||||
- Contributions Welcome
|
||||
- Development Blocker
|
||||
- Ease of Use
|
||||
- Error handling
|
||||
- HTTP
|
||||
- Incompatible
|
||||
- Stable API
|
||||
|
|
|
@ -24,7 +24,7 @@ This document contains various instructions relevant for Druid committers.
|
|||
This checklist describes steps that every committer should take for their own issues and PRs and when they are the first
|
||||
committer who visits an issue or a PR authored by a non-committer.
|
||||
|
||||
1. Add appropriate tags to the PR, in particular:
|
||||
1. Add appropriate labels to the PR, in particular:
|
||||
|
||||
- [**`Design Review`**](https://github.com/apache/incubator-druid/labels/Design%20Review) - for changes that will be
|
||||
hard to undo after they appear in some Druid release, and/or changes that will have lasting consequences in the
|
||||
|
@ -40,7 +40,7 @@ committer who visits an issue or a PR authored by a non-committer.
|
|||
- Other major changes
|
||||
|
||||
PRs that flesh out community standards, checklists, policies, and PRs that change issue and PR templates, in other
|
||||
words, many of the PRs tagged `Area - Dev` should often be tagged `Design Review` as well.
|
||||
words, many of the PRs labelled `Area - Dev` should often be labelled `Design Review` as well.
|
||||
|
||||
The PR description should succinctly, but completely list all public API elements (`@PublicApi` or
|
||||
`@ExtensionPoint`), configuration options, emitted metric names, HTTP endpoint paths and parameters that are added
|
||||
|
@ -59,18 +59,18 @@ committer who visits an issue or a PR authored by a non-committer.
|
|||
needed), and the ability to roll back to at least the immediate prior Druid version. If a change makes either one
|
||||
of these impossible then it should be re-designed.
|
||||
|
||||
All `Incompatible` PRs should be tagged `Design Review` too, but not vice versa: some `Design Review` issues,
|
||||
All `Incompatible` PRs should be labelled `Design Review` too, but not vice versa: some `Design Review` issues,
|
||||
proposals and PRs may not be `Incompatible`.
|
||||
|
||||
- [**`Release Notes`**](https://github.com/apache/incubator-druid/labels/Release%20Notes) - for important changes
|
||||
that should be reflected in the next Druid’s version release notes. Critically, those are changes that require some
|
||||
server or query configuration changes made by Druid cluster operators to preserve the former cluster behaviour, i. e.
|
||||
the majority of PRs tagged `Incompatible`. However, some `Incompatible` PRs may not need to be tagged
|
||||
the majority of PRs labelled `Incompatible`. However, some `Incompatible` PRs may not need to be labelled
|
||||
`Release Notes`, e. g. PRs that only change some extension APIs, because when building extensions with the newer
|
||||
Druid version the incompatibility will be discovered anyway.
|
||||
|
||||
Secondarily, PRs that add new features, improve performance or improve Druid cluster operation experience could
|
||||
also be tagged `Release Notes` at your discretion.
|
||||
also be labelled `Release Notes` at your discretion.
|
||||
|
||||
- [**`Bug`**](https://github.com/apache/incubator-druid/labels/Bug) / [**`Security`**](
|
||||
https://github.com/apache/incubator-druid/labels/Security) / [**`Feature`**](
|
||||
|
@ -78,7 +78,7 @@ committer who visits an issue or a PR authored by a non-committer.
|
|||
https://github.com/apache/incubator-druid/labels/Performance) / [**`Refactoring`**](
|
||||
https://github.com/apache/incubator-druid/labels/Refactoring) / [**`Improvement`**](
|
||||
https://github.com/apache/incubator-druid/labels/Improvement) - can be used to distinguish between types of changes.
|
||||
[**`Compatibility`**](https://github.com/apache/incubator-druid/labels/Compatibility) tag also falls into this
|
||||
[**`Compatibility`**](https://github.com/apache/incubator-druid/labels/Compatibility) label also falls into this
|
||||
category, it's specifically for PRs that restore or improve compatibility with previous Druid versions if it was
|
||||
inadvertently broken, or for changes that ensure forward compatibility with future Druid versions, forseening specific
|
||||
changes that would otherwise break the compatibility.
|
||||
|
@ -87,11 +87,11 @@ committer who visits an issue or a PR authored by a non-committer.
|
|||
that need to be merged before some other PRs could even be published. `Development Blocker` PRs should be prioritized
|
||||
by reviewers, so that they could be merged as soon as possible, thus not blocking somebody's work.
|
||||
|
||||
2. If you added some tags on the previous step, describe why did you do that, either in the PR description (if you are
|
||||
the author of the PR) or in a comment (if you have added tags to a PR submitted by someone else).
|
||||
2. If you added some labels on the previous step, describe why did you do that, either in the PR description (if you are
|
||||
the author of the PR) or in a comment (if you have added labels to a PR submitted by someone else).
|
||||
|
||||
3. Consider adding one or several **`Area -`** tags to the PR or issue. Consider [creating a new `Area -` tag](
|
||||
#creating-a-new-tag-on-github) if none of the existing `Area` tags is applicable to the PR or issue.
|
||||
3. Consider adding one or several **`Area -`** labels to the PR or issue. Consider [creating a new `Area -` label](
|
||||
#creating-a-new-label-on-github) if none of the existing `Area` labels is applicable to the PR or issue.
|
||||
|
||||
- [`Area - Automation/Static Analysis`](
|
||||
https://github.com/apache/incubator-druid/labels/Area%20-%20Automation%2FStatic%20Analysis) - for any PRs and issues
|
||||
|
@ -102,13 +102,13 @@ the author of the PR) or in a comment (if you have added tags to a PR submitted
|
|||
- [`Area - Dev`](https://github.com/apache/incubator-druid/labels/Area%20-%20Dev) - for PRs and issues related to the
|
||||
project itself, such as adding developer's docs and checklists, Github issue and PR templates, Github-related issues.
|
||||
Don't use for PRs and issues related to CI problems: use either `Area - Testing` for problems with Travis or
|
||||
`Area - Automation/Static Analysis` for problems with TeamCity. PRs with `Area - Dev` tag should usually change files
|
||||
in `dev/` or `.github/` directories.
|
||||
`Area - Automation/Static Analysis` for problems with TeamCity. PRs with `Area - Dev` label should usually change
|
||||
files in `dev/` or `.github/` directories.
|
||||
- [`Area - Documentation`](https://github.com/apache/incubator-druid/labels/Area%20-%20Documentation) - for PRs and
|
||||
issues about Druid's documentation for users and cluster operators. Don't use for PRs and issues about the
|
||||
documentation of the Druid's development process itself: use `Area - Dev` for that purpose. Don't use for issues and
|
||||
PR regarding adding internal design documentation and specification to code, usually, in the form of Javadocs or
|
||||
comments (there is no specialized tag for this).
|
||||
comments (there is no specialized label for this).
|
||||
- [`Area - Lookups`](https://github.com/apache/incubator-druid/labels/Area%20-%20Lookups) - for PRs and issues
|
||||
related to Druid's Query Time Lookups (QTL) feature.
|
||||
- [`Area - Null Handling`](https://github.com/apache/incubator-druid/labels/Area%20-%20Null%20Handling) - for PRs and
|
||||
|
@ -124,12 +124,12 @@ the author of the PR) or in a comment (if you have added tags to a PR submitted
|
|||
- [`Area - Segment Balancing/Coordination`](
|
||||
https://github.com/apache/incubator-druid/labels/Area%20-%20Segment%20Balancing%2FCoordination) - for PRs and issue
|
||||
related to the process of loading and dropping segments in Druid clusters according to specified *rules*, and
|
||||
balancing segments between Historical nodes in clusters. Coordinator node is responsible for both processes. This tag
|
||||
is not called "Area - Coordinator" because Coordinator has some other duties that are not covered by this tag, for
|
||||
example, compacting segments.
|
||||
balancing segments between Historical nodes in clusters. Coordinator node is responsible for both processes. This
|
||||
label is not called "Area - Coordinator" because Coordinator has some other duties that are not covered by this
|
||||
label, for example, compacting segments.
|
||||
- [`Area - Testing`](https://github.com/apache/incubator-druid/labels/Area%20-%20Testing) - use for any PRs and
|
||||
issues related to testing (including integration testing), Travis CI issues, and flaky tests. For flaky tests, also
|
||||
add [`Flaky test`](https://github.com/apache/incubator-druid/labels/Flaky%20test) tag.
|
||||
add [`Flaky test`](https://github.com/apache/incubator-druid/labels/Flaky%20test) label.
|
||||
- [`Area - Zookeeper/Curator`](https://github.com/apache/incubator-druid/labels/Area%20-%20Zookeeper%2FCurator) - for
|
||||
any PRs and issues related to ZooKeeper, Curator, and node discovery in Druid.
|
||||
|
||||
|
@ -143,7 +143,7 @@ committed, to avoid cluttering the release manager's workflow.
|
|||
problems even if you don't plan to review the PR.
|
||||
|
||||
6. If you create an issue that is relatively small and self-contained and you don't plan to work on it in the near
|
||||
future, consider tagging it [**`Contributions Welcome`**](
|
||||
future, consider labelling it [**`Contributions Welcome`**](
|
||||
https://github.com/apache/incubator-druid/labels/Contributions%20Welcome) so that other people know that the issue is
|
||||
free to pick up and is relatively easily doable even for those who are not very familiar with the codebase.
|
||||
|
||||
|
@ -159,17 +159,19 @@ number (such as 0.10.1, while the previous release is 0.10 or 0.10.0), rename th
|
|||
|
||||
4. Consider thanking the author for contribution, especially a new contributor.
|
||||
|
||||
## Creating a new tag on Github
|
||||
## Creating a new label on Github
|
||||
|
||||
After creating a tag for your PR or issue, don't forget to take the following steps:
|
||||
After creating a new label for your PR or issue, don't forget to take the following steps:
|
||||
|
||||
1. Search existing PRs and issues and try to add the new tag to at least three of them.
|
||||
1. Search existing PRs and issues and try to add the new label to at least three of them.
|
||||
|
||||
2. Describe the new tag in the [PR and issue action item checklist for committers](
|
||||
2. Describe the new label in the [PR and issue action item checklist for committers](
|
||||
#pr-and-issue-action-item-checklist-for-committers) above.
|
||||
|
||||
3. Although it is *not* necessary to preliminarily discuss creation of a new tag in the developers' mailing list, please
|
||||
announce the new tag after you've created it at `dev@druid.apache.org`.
|
||||
3. Add the label to stalebot's excemptions if needed: see [`stale.yml`](../.github/stale.yml).
|
||||
|
||||
4. Although it is *not* necessary to preliminarily discuss creation of a new label in the developers' mailing list,
|
||||
please announce the new label after you've created it at `dev@druid.apache.org`.
|
||||
|
||||
## Become an Administrator of the Druid project in TeamCity
|
||||
|
||||
|
|
Loading…
Reference in New Issue