You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airflow.apache.org by Vikram Koka <vi...@astronomer.io> on 2020/11/03 02:32:49 UTC
Re: [Meeting Notes] Airflow issue triage process - Call #1 - Oct 20 2020
Hi all,
I wanted to invite you to a follow-up call on the Airflow issue triage
process.
*Date*: November 5th
*Time*: 8.30--9.30 AM Pacific / 4.30 - 5.30 PM GMT
*Zoom link*:
https://astronomer.zoom.us/j/96659511795?pwd=MVd2VjVKVEdtRG5vTGN3VXNXZEJPdz09
<https://www.google.com/url?q=https://astronomer.zoom.us/j/96659511795?pwd%3DMVd2VjVKVEdtRG5vTGN3VXNXZEJPdz09&sa=D&source=calendar&ust=1603062773118000&usg=AOvVaw3NILdQFS5CXdYmOD1HuvpK>
Agenda for today's call:
- Follow-up feedback from decisions of last call
- Learnings from issues currently being processed
- Discuss triage party
Best regards,
Vikram
On Tue, Oct 27, 2020 at 1:07 PM Jarek Potiuk <Ja...@polidea.com>
wrote:
> Thanks Vikram!
>
> I will try to join the next meeting and see if I can help with anything
> (providing that the CI and providers will not be eating all of my time.
>
> J.
>
> On Tue, Oct 27, 2020 at 4:51 AM Vikram Koka <vi...@astronomer.io> wrote:
>
>> Hi all,
>>
>> I have updated our meeting notes document to summarize the discussion
>> from our call last week. Sorry that it took so long.
>> Thank you all who joined the call.
>>
>> To all those who attended, can you please double-check and add if I
>> missed anything?
>> To all those who didn't join, if you disagree to anything covered, please
>> voice your opinion.
>> Also, please let me know if you want to include anything in Next call's
>> Agenda.
>> *Key Decisions:*
>>
>> -
>>
>> Labels
>> -
>>
>> Purpose: Labels should be non-temporal in nature and should
>> indicate the following two elements:
>> -
>>
>> “Kind” should indicate “what kind of issue it is” i.e. “bug”,
>> “feature”, “doc change”, “performance improvement”
>> -
>>
>> “Area” should indicate the area of the code: Scheduler, Webserver,
>> etc. One use of the “Area” is to say who/which group of people should
>> review the PR. For example, Daniel filters by “area/kubernetes” which makes
>> it easier to find it.
>>
>>
>>
>> -
>>
>> Products should be folded into “area”. So, “area/helm-chart”
>> -
>>
>> “Need” which is a temporary state for an issue, before the above
>> two labels are assigned. Primarily, until one or more committers can weigh
>> in, though some may need discussion on the mailing list.
>> -
>>
>> What should they be: An initial non-exhaustive list of all the
>> labels is below.
>> -
>>
>> kind/bug, kind/feature, kind/documentation, kind/performance
>> -
>>
>> kind/enhancement: this is an improvement to an existing feature.
>> This is somewhat subjective vs. a new feature, but this is useful to
>> generate a change log as part of a release.
>>
>>
>>
>> -
>>
>> area/webserver, area/scheduler, area/executor, area/providers
>> (area/providers/google, area/providers/amazon, area/providers/azure,
>> area/providers/other)
>> -
>>
>> Currently, we also have area/providers/apache, but that should be
>> replaced by area/providers/other
>> -
>>
>> area/webserver - includes User Interface (and UX)
>> -
>>
>> area/docker-image
>> -
>>
>> area/kubernetes - can be used along with other areas, to reflect
>> that this touches kubernetes. For example, an issue could have both:
>> area/executor and area/kubernetes
>> -
>>
>> area/breeze
>> -
>>
>> area/helm-chart
>> -
>>
>> area/core - covers anything else
>> -
>>
>> Others to be deprecated include: area/logging which would now be
>> included in area/core
>>
>>
>>
>> -
>>
>> need/discussion: some method to get discussion from committers,
>> but is not specifically an issue for a particular area.
>> -
>>
>> Example: Issue opened regarding “deprecating mssql hook”.
>> https://github.com/apache/airflow/issues/8458 Should we still do
>> this or not? Not necessarily, something that needs to be on the dev mailing
>> list.
>> -
>>
>>
>> -
>>
>> need/triage: default starting point for an issue.
>> -
>>
>> “Need” labels are intended to be temporary, until they can be
>> processed. These should not be long lived. Only needed until one or more
>> committers can weigh in.
>>
>>
>>
>> -
>>
>> What labels should not be touched because of release management:
>> “pinned” - only relevant for PRs, not for issues.
>> -
>>
>> Labels for community development: Good-first-issue, hacktoberfest
>> -
>>
>>
>> -
>>
>> Epic? - Let’s use milestones or projects for Epics. Let’s not
>> clutter up the label list with temporary labels for AIPs or Epics.
>>
>>
>>
>> -
>>
>> How / when assigned:
>> -
>>
>> Automatically any new issue will be added a “need/triage” label.
>> And then when one of “us” is going over the new issues, the labels from
>> this document will be added/applied.
>>
>>
>>
>> -
>>
>> Milestones
>> -
>>
>> Purpose: Temporal in nature. Useful for release management
>> purposes. Will generally be used to represent releases (targets)
>> -
>>
>> Examples: What issues do we want to get into a particular release?
>> Or, what releases do we want to backport issues to?
>> -
>>
>> Feature releases - may need a milestone such as 2.1
>> -
>>
>> Patch releases - may be more Kanban style, but may have a
>> milestone as well such as 2.0.1
>> -
>>
>> Milestone on a PR implies: This PR should be merged into that
>> particular release
>> -
>>
>> Milestone on an Issue: Target issue resolution for that release.
>> -
>>
>> What should they be:
>> -
>>
>> Right now, useful milestones: 2.0beta1, 2.0beta2, 2.0rc1, 1.10.13
>> (critical bug fixes only)
>> -
>>
>> Providers will be independently versioned and be in small releases
>> - so potentially can just use kanban style.
>>
>>
>>
>> -
>>
>> Priority
>> -
>>
>> Purpose: Yes, let’s use priorities.
>> -
>>
>> What should they be: Google vs. Kubernetes vs. other.
>> -
>>
>> Let’s use Kubernetes style priorities, as opposed to the Google
>> style priorities, since they are easier to understand for most people.
>> -
>>
>> This is primarily for prioritization and release management.
>>
>>
>> *Next steps:*
>>
>> -
>>
>> Update google doc - Vikram
>> -
>>
>> Send to dev list - Vikram
>> -
>>
>> Follow-up call next Tuesday? - Vikram to schedule
>> -
>>
>> Investigate applying these by next call - Paola
>> -
>>
>> Discuss Tooling in the next call. Triage party proposed by Kamil.
>>
>>
>>
>> *Doc links*:
>> *Meeting notes*:
>> https://docs.google.com/document/d/1Fx46SoOnNLiqZKtrC-tOHj3zFlZfQwWuR2LRFXJnWqw/
>> *Original doc*:
>> https://docs.google.com/document/d/1jqmXO6mGZzHkhuvISedQVnhyc37V_iz00hokdMuoFaI/
>>
>> Best regards,
>>
>> Vikram
>>
>>
>>
>>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>
>
Re: [Meeting Notes] Airflow issue triage process - Call #1 - Oct 20 2020
Posted by Jarek Potiuk <Ja...@polidea.com>.
Marked in my calendar
On Tue, Nov 3, 2020 at 3:33 AM Vikram Koka <vi...@astronomer.io> wrote:
> Hi all,
>
> I wanted to invite you to a follow-up call on the Airflow issue triage
> process.
>
> *Date*: November 5th
> *Time*: 8.30--9.30 AM Pacific / 4.30 - 5.30 PM GMT
> *Zoom link*:
> https://astronomer.zoom.us/j/96659511795?pwd=MVd2VjVKVEdtRG5vTGN3VXNXZEJPdz09
> <https://www.google.com/url?q=https://astronomer.zoom.us/j/96659511795?pwd%3DMVd2VjVKVEdtRG5vTGN3VXNXZEJPdz09&sa=D&source=calendar&ust=1603062773118000&usg=AOvVaw3NILdQFS5CXdYmOD1HuvpK>
>
> Agenda for today's call:
>
> - Follow-up feedback from decisions of last call
> - Learnings from issues currently being processed
> - Discuss triage party
>
>
> Best regards,
>
> Vikram
>
>
>
>
> On Tue, Oct 27, 2020 at 1:07 PM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
>> Thanks Vikram!
>>
>> I will try to join the next meeting and see if I can help with anything
>> (providing that the CI and providers will not be eating all of my time.
>>
>> J.
>>
>> On Tue, Oct 27, 2020 at 4:51 AM Vikram Koka <vi...@astronomer.io> wrote:
>>
>>> Hi all,
>>>
>>> I have updated our meeting notes document to summarize the discussion
>>> from our call last week. Sorry that it took so long.
>>> Thank you all who joined the call.
>>>
>>> To all those who attended, can you please double-check and add if I
>>> missed anything?
>>> To all those who didn't join, if you disagree to anything covered,
>>> please voice your opinion.
>>> Also, please let me know if you want to include anything in Next call's
>>> Agenda.
>>> *Key Decisions:*
>>>
>>> -
>>>
>>> Labels
>>> -
>>>
>>> Purpose: Labels should be non-temporal in nature and should
>>> indicate the following two elements:
>>> -
>>>
>>> “Kind” should indicate “what kind of issue it is” i.e. “bug”,
>>> “feature”, “doc change”, “performance improvement”
>>> -
>>>
>>> “Area” should indicate the area of the code: Scheduler,
>>> Webserver, etc. One use of the “Area” is to say who/which group of people
>>> should review the PR. For example, Daniel filters by “area/kubernetes”
>>> which makes it easier to find it.
>>>
>>>
>>>
>>> -
>>>
>>> Products should be folded into “area”. So, “area/helm-chart”
>>> -
>>>
>>> “Need” which is a temporary state for an issue, before the above
>>> two labels are assigned. Primarily, until one or more committers can weigh
>>> in, though some may need discussion on the mailing list.
>>> -
>>>
>>> What should they be: An initial non-exhaustive list of all the
>>> labels is below.
>>> -
>>>
>>> kind/bug, kind/feature, kind/documentation, kind/performance
>>> -
>>>
>>> kind/enhancement: this is an improvement to an existing feature.
>>> This is somewhat subjective vs. a new feature, but this is useful to
>>> generate a change log as part of a release.
>>>
>>>
>>>
>>> -
>>>
>>> area/webserver, area/scheduler, area/executor, area/providers
>>> (area/providers/google, area/providers/amazon, area/providers/azure,
>>> area/providers/other)
>>> -
>>>
>>> Currently, we also have area/providers/apache, but that should be
>>> replaced by area/providers/other
>>> -
>>>
>>> area/webserver - includes User Interface (and UX)
>>> -
>>>
>>> area/docker-image
>>> -
>>>
>>> area/kubernetes - can be used along with other areas, to reflect
>>> that this touches kubernetes. For example, an issue could have both:
>>> area/executor and area/kubernetes
>>> -
>>>
>>> area/breeze
>>> -
>>>
>>> area/helm-chart
>>> -
>>>
>>> area/core - covers anything else
>>> -
>>>
>>> Others to be deprecated include: area/logging which would now be
>>> included in area/core
>>>
>>>
>>>
>>> -
>>>
>>> need/discussion: some method to get discussion from committers,
>>> but is not specifically an issue for a particular area.
>>> -
>>>
>>> Example: Issue opened regarding “deprecating mssql hook”.
>>> https://github.com/apache/airflow/issues/8458 Should we still do
>>> this or not? Not necessarily, something that needs to be on the dev mailing
>>> list.
>>> -
>>>
>>>
>>> -
>>>
>>> need/triage: default starting point for an issue.
>>> -
>>>
>>> “Need” labels are intended to be temporary, until they can be
>>> processed. These should not be long lived. Only needed until one or more
>>> committers can weigh in.
>>>
>>>
>>>
>>> -
>>>
>>> What labels should not be touched because of release management:
>>> “pinned” - only relevant for PRs, not for issues.
>>> -
>>>
>>> Labels for community development: Good-first-issue, hacktoberfest
>>> -
>>>
>>>
>>> -
>>>
>>> Epic? - Let’s use milestones or projects for Epics. Let’s not
>>> clutter up the label list with temporary labels for AIPs or Epics.
>>>
>>>
>>>
>>> -
>>>
>>> How / when assigned:
>>> -
>>>
>>> Automatically any new issue will be added a “need/triage” label.
>>> And then when one of “us” is going over the new issues, the labels from
>>> this document will be added/applied.
>>>
>>>
>>>
>>> -
>>>
>>> Milestones
>>> -
>>>
>>> Purpose: Temporal in nature. Useful for release management
>>> purposes. Will generally be used to represent releases (targets)
>>> -
>>>
>>> Examples: What issues do we want to get into a particular
>>> release? Or, what releases do we want to backport issues to?
>>> -
>>>
>>> Feature releases - may need a milestone such as 2.1
>>> -
>>>
>>> Patch releases - may be more Kanban style, but may have a
>>> milestone as well such as 2.0.1
>>> -
>>>
>>> Milestone on a PR implies: This PR should be merged into that
>>> particular release
>>> -
>>>
>>> Milestone on an Issue: Target issue resolution for that release.
>>> -
>>>
>>> What should they be:
>>> -
>>>
>>> Right now, useful milestones: 2.0beta1, 2.0beta2, 2.0rc1, 1.10.13
>>> (critical bug fixes only)
>>> -
>>>
>>> Providers will be independently versioned and be in small
>>> releases - so potentially can just use kanban style.
>>>
>>>
>>>
>>> -
>>>
>>> Priority
>>> -
>>>
>>> Purpose: Yes, let’s use priorities.
>>> -
>>>
>>> What should they be: Google vs. Kubernetes vs. other.
>>> -
>>>
>>> Let’s use Kubernetes style priorities, as opposed to the Google
>>> style priorities, since they are easier to understand for most people.
>>> -
>>>
>>> This is primarily for prioritization and release management.
>>>
>>>
>>> *Next steps:*
>>>
>>> -
>>>
>>> Update google doc - Vikram
>>> -
>>>
>>> Send to dev list - Vikram
>>> -
>>>
>>> Follow-up call next Tuesday? - Vikram to schedule
>>> -
>>>
>>> Investigate applying these by next call - Paola
>>> -
>>>
>>> Discuss Tooling in the next call. Triage party proposed by Kamil.
>>>
>>>
>>>
>>> *Doc links*:
>>> *Meeting notes*:
>>> https://docs.google.com/document/d/1Fx46SoOnNLiqZKtrC-tOHj3zFlZfQwWuR2LRFXJnWqw/
>>> *Original doc*:
>>> https://docs.google.com/document/d/1jqmXO6mGZzHkhuvISedQVnhyc37V_iz00hokdMuoFaI/
>>>
>>> Best regards,
>>>
>>> Vikram
>>>
>>>
>>>
>>>
>>
>> --
>>
>> Jarek Potiuk
>> Polidea <https://www.polidea.com/> | Principal Software Engineer
>>
>> M: +48 660 796 129 <+48660796129>
>> [image: Polidea] <https://www.polidea.com/>
>>
>>
--
Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer
M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>