Re: [DISCUSS] Trimming down Airlfow Versions in issues

[Jarek Potiuk <ja...@potiuk.com>]

To focus on a possible solution - I created a PR with the removal of all
the versions but the latest from a given branch and updated the description
- https://github.com/apache/airflow/pull/25480

Let me know what you think.

J.

On Wed, Jul 27, 2022 at 4:52 PM Jarek Potiuk <ja...@potiuk.com> wrote:

> Other ideas/opinions here?
>
> On Thu, Jul 21, 2022 at 2:05 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>
>> Just to comment. I do not think everyone will be able to upgrade (and
>> if they don't the "discussion" route is still possible).
>>
>> This is more of a "psychological barrier" that I am talking about
>> here. I've learned recently that making things "easy and smooth" is
>> not always the best approach. Sometimes it is good to create a bit of
>> friction, to make people think.
>>
>> Imagine you are a user.
>>
>> If you see your version on the list, you immediately assume that it's
>> ok to create an issue - and you don't even think about alternatives.
>> When you don't see it, there is a non-zero chance you will pause for a
>> moment, and maybe (just maybe) you will see that the recommendation is
>> to upgrade just above the list, when you will be looking for
>> alternatives.
>>
>> And there is no chance to achieve 100% accurate behaviour change (and
>> it's not my intention).
>>
>> * There will be people who will add their version in the description
>> ("actually I am using 2.3.2 but could not choose it")
>> * There will be people who will not even write that and choose another
>> version (but those people possibly already chose a random version from
>> the too-long list - we can't prevent that).
>> * There will be people who will open "discussion" instead (which is
>> cool and that's my intention as well - we can always bring it back as
>> an issue)
>>
>> * Finally - there will be people who will realise - ok, maybe indeed I
>> should upgrade (mostly those will be smaller installations, easy to
>> upgrade, but those people maybe did not realise there is a new version
>> that they can easily upgrade to) -> THIS is precisely the group of
>> people I want to address with the change.
>>
>> So my goal is - if there are people from the latest group who will
>> pause at the issue entering, and who will instead perform a group ->
>> my goal is achieved. I think even if it is a small group of people,
>> they tend to open more issues (as they are less experienced) and their
>> issue descriptions are of a lesser quality - which means that
>> diagnosing and helping them takes more time. So if you can make those
>> - even small - group people into upgrading before reporting an issue
>> (and potentially not reporting the issue at all), this is a win-win
>> situation. They resolve their problems faster, we have more time and
>> less issues to look at.
>>
>> J.
>>
>> On Thu, Jul 21, 2022 at 1:24 PM Elad Kalif <el...@apache.org> wrote:
>> >
>> > In general I agree but in I don't think this is going to work as you
>> expect because not all users are able to upgrade to the latest minor
>> version easily.
>> > I can say for myself I'm on 2.2.3 and I can not upgrade - even not to
>> 2.2.5
>> > The reason is not related to Airflow at all but more to an internal
>> policy (I can explain why but not sure it's relevant for this discussion)
>> >
>> > I am concerned that limiting the list will result in false reports of
>> versions which may cause confusion for us.
>> >
>> > That said, I think we can consider just removing all 2.0 and 2.1 series
>> from the list.
>> > The reason I'm suggesting this is - everytime I see an issue on these
>> versions I ask "is it reproducible on main/latest version?" and wait for
>> the user to reply.
>> > So we can explain that in the case of  2.0 and 2.1 series bug reports
>> we ask users to check the issue on the latest version and submit the bug
>> report on that version.
>> >
>> >
>> > On Thu, Jul 21, 2022 at 12:35 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>> >>
>> >> (second line should be 2.3.2 -> for a few days after 2.3.3 is released
>> >>
>> >> On Thu, Jul 21, 2022 at 11:34 AM Jarek Potiuk <ja...@potiuk.com>
>> wrote:
>> >> >
>> >> > Hello everyone,
>> >> >
>> >> > I've looked at some issues raised recently and I have an idea on how
>> >> > to make diagnosis of problems raised by our users a bit more
>> >> > "efficient". It should also help to address "version" proliferation
>> ve
>> >> > have in the issue template.
>> >> >
>> >> > The list grows longer and longer the more releases we make, however -
>> >> > more often than not whenever someone reports an issue on (say 2.2.1),
>> >> > and we "suspect" the problem might be solved already we suggest the
>> >> > users to upgrade first to at least latest in 2.2.* line and see if it
>> >> > works.
>> >> >
>> >> > As counterintuitive as it seems for an engineer, it might often be
>> the
>> >> > faster solution - similarly like "bisecting" is a good way of finding
>> >> > a solution without knowing the root cause is, upgrading to the latest
>> >> > version in the line might often be the best idea to solve a problem.
>> >> > Maybe we do not know the root cause, but if the problem is solved. It
>> >> > means that the result is achieved (i.e. problem solved) and the
>> >> > problem has been investigated and solved (or maybe it was solved
>> >> > accidentally but it does not make it "less solved").
>> >> >
>> >> > Now - maybe we should consider to build our list of versions this way
>> >> > (Compare it to the current long list we have there now).
>> >> >
>> >> > * 2.3.3 -> latest
>> >> > * 2.3.3 -> for a few days after 2.3.3 is released
>> >> > * 2.2.5
>> >> > * 2.1.4
>> >> > * 2.0.2
>> >> > * main (development)
>> >> >
>> >> >
>> >> > And update the note above similar to:
>> >> >
>> >> > Only Airflow 2 is supported for bugs. If you do not see your version
>> >> > here please upgrade to the latest version in your Y.X line and check
>> >> > if your issue is solved there before reporting or open discussion
>> >> > instead.
>> >> >
>> >> > Upgrading to the latest bugfix version should generally always
>> happen.
>> >> > If the user does not do it, they miss the latest bug-fixes in the
>> line
>> >> > and risk really nothing.
>> >> >
>> >> > I think this might have some nice effects:
>> >> >
>> >> > * people might upgrade earlier
>> >> > * no time lost on diagnosing of already solved issues by both -
>> >> > reporting users and those who try to help
>> >> > * stronger communication of "we really support only latest versions
>> >> > from the line
>> >> > * potentially faster rollout and pressure on managed versions of
>> >> > Airflow to upgrade to the latest bugfix - as their users might start
>> >> > asking the questions to them rather than to us if they do not see the
>> >> > version on the list.
>> >> >
>> >> > WDYT?
>> >> >
>> >> > J.
>>
>

Re: [DISCUSS] Trimming down Airlfow Versions in issues

[Jarek Potiuk <ja...@potiuk.com>]

Crearted PR here: https://github.com/apache/airflow/pull/25564

On Sat, Aug 6, 2022 at 9:26 AM Jarek Potiuk <ja...@potiuk.com> wrote:

> Free text field seems better for those. But we should make it required :)
>
> On Sat, Aug 6, 2022 at 1:40 AM Jed Cunningham <je...@apache.org>
> wrote:
>
>> So far we've been talking about Airflow core bugs, but we do have 2 other
>> issue templates that ask for the Airflow version - chart and providers.
>>
>> Both of those ultimately do support non-latest core versions, so I don't
>> think we can be quite as blunt there. We either keep the full list or
>> convert to a free text field.
>>
>> I don't have a strong preference here. Anyone have any thoughts?
>>
>>
>> On Thu, Aug 4, 2022 at 5:44 PM Jeambrun Pierre <pi...@gmail.com>
>> wrote:
>>
>>> Same, great idea :)
>>>
>>> On Fri 5 Aug 2022 at 01:43, Vikram Koka <vi...@astronomer.io.invalid>
>>> wrote:
>>>
>>>> +1 on this approach with this approach in the PR
>>>> https://github.com/apache/airflow/pull/25542
>>>>
>>>>
>>>>
>>>> On Thu, Aug 4, 2022 at 12:40 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>>>>
>>>>> Love it.
>>>>>
>>>>> On Thu, Aug 4, 2022 at 9:28 PM Jed Cunningham <
>>>>> jedcunningham@apache.org> wrote:
>>>>>
>>>>>> Sorry, coming to this a little late. I tend to agree with Elad that
>>>>>> we might be better off not even having 2.0/2.1, and I'll go further that we
>>>>>> should consider only listing main/latest/possibly n-1(e.g. 2.3.2).
>>>>>>
>>>>>> I'm also concerned only showing the latest in every minor may imply
>>>>>> those are all getting bugfixes, while in fact only 2.3.x is. Plus, even if
>>>>>> we tell people to upgrade to the latest 2.2.x version (2.2.5 from 2.2.2,
>>>>>> for example) before reporting, the first thing we are going to ask in the
>>>>>> issue is "what about 2.3.3/main?".
>>>>>>
>>>>>> Another option is a free test field instead, though this doesn't
>>>>>> provide the subtle hint you are after.
>>>>>>
>>>>>> If we don't make it a free text field and don't enumerate all the
>>>>>> versions, we almost certainly want an "other" option? I'd rather give them
>>>>>> that escape hatch then have the wrong version in the easy to spot section
>>>>>> and their real version hidden in a wall of text.
>>>>>>
>>>>>> I've opened this to take your change a bit further:
>>>>>> https://github.com/apache/airflow/pull/25542
>>>>>>
>>>>>

Re: [DISCUSS] Trimming down Airlfow Versions in issues

[Jarek Potiuk <ja...@potiuk.com>]

Free text field seems better for those. But we should make it required :)

On Sat, Aug 6, 2022 at 1:40 AM Jed Cunningham <je...@apache.org>
wrote:

> So far we've been talking about Airflow core bugs, but we do have 2 other
> issue templates that ask for the Airflow version - chart and providers.
>
> Both of those ultimately do support non-latest core versions, so I don't
> think we can be quite as blunt there. We either keep the full list or
> convert to a free text field.
>
> I don't have a strong preference here. Anyone have any thoughts?
>
>
> On Thu, Aug 4, 2022 at 5:44 PM Jeambrun Pierre <pi...@gmail.com>
> wrote:
>
>> Same, great idea :)
>>
>> On Fri 5 Aug 2022 at 01:43, Vikram Koka <vi...@astronomer.io.invalid>
>> wrote:
>>
>>> +1 on this approach with this approach in the PR
>>> https://github.com/apache/airflow/pull/25542
>>>
>>>
>>>
>>> On Thu, Aug 4, 2022 at 12:40 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>>>
>>>> Love it.
>>>>
>>>> On Thu, Aug 4, 2022 at 9:28 PM Jed Cunningham <je...@apache.org>
>>>> wrote:
>>>>
>>>>> Sorry, coming to this a little late. I tend to agree with Elad that we
>>>>> might be better off not even having 2.0/2.1, and I'll go further that we
>>>>> should consider only listing main/latest/possibly n-1(e.g. 2.3.2).
>>>>>
>>>>> I'm also concerned only showing the latest in every minor may imply
>>>>> those are all getting bugfixes, while in fact only 2.3.x is. Plus, even if
>>>>> we tell people to upgrade to the latest 2.2.x version (2.2.5 from 2.2.2,
>>>>> for example) before reporting, the first thing we are going to ask in the
>>>>> issue is "what about 2.3.3/main?".
>>>>>
>>>>> Another option is a free test field instead, though this doesn't
>>>>> provide the subtle hint you are after.
>>>>>
>>>>> If we don't make it a free text field and don't enumerate all the
>>>>> versions, we almost certainly want an "other" option? I'd rather give them
>>>>> that escape hatch then have the wrong version in the easy to spot section
>>>>> and their real version hidden in a wall of text.
>>>>>
>>>>> I've opened this to take your change a bit further:
>>>>> https://github.com/apache/airflow/pull/25542
>>>>>
>>>>

Re: [DISCUSS] Trimming down Airlfow Versions in issues

[Jed Cunningham <je...@apache.org>]

So far we've been talking about Airflow core bugs, but we do have 2 other
issue templates that ask for the Airflow version - chart and providers.

Both of those ultimately do support non-latest core versions, so I don't
think we can be quite as blunt there. We either keep the full list or
convert to a free text field.

I don't have a strong preference here. Anyone have any thoughts?


On Thu, Aug 4, 2022 at 5:44 PM Jeambrun Pierre <pi...@gmail.com>
wrote:

> Same, great idea :)
>
> On Fri 5 Aug 2022 at 01:43, Vikram Koka <vi...@astronomer.io.invalid>
> wrote:
>
>> +1 on this approach with this approach in the PR
>> https://github.com/apache/airflow/pull/25542
>>
>>
>>
>> On Thu, Aug 4, 2022 at 12:40 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>>
>>> Love it.
>>>
>>> On Thu, Aug 4, 2022 at 9:28 PM Jed Cunningham <je...@apache.org>
>>> wrote:
>>>
>>>> Sorry, coming to this a little late. I tend to agree with Elad that we
>>>> might be better off not even having 2.0/2.1, and I'll go further that we
>>>> should consider only listing main/latest/possibly n-1(e.g. 2.3.2).
>>>>
>>>> I'm also concerned only showing the latest in every minor may imply
>>>> those are all getting bugfixes, while in fact only 2.3.x is. Plus, even if
>>>> we tell people to upgrade to the latest 2.2.x version (2.2.5 from 2.2.2,
>>>> for example) before reporting, the first thing we are going to ask in the
>>>> issue is "what about 2.3.3/main?".
>>>>
>>>> Another option is a free test field instead, though this doesn't
>>>> provide the subtle hint you are after.
>>>>
>>>> If we don't make it a free text field and don't enumerate all the
>>>> versions, we almost certainly want an "other" option? I'd rather give them
>>>> that escape hatch then have the wrong version in the easy to spot section
>>>> and their real version hidden in a wall of text.
>>>>
>>>> I've opened this to take your change a bit further:
>>>> https://github.com/apache/airflow/pull/25542
>>>>
>>>

Re: [DISCUSS] Trimming down Airlfow Versions in issues

[Jeambrun Pierre <pi...@gmail.com>]

Same, great idea :)

On Fri 5 Aug 2022 at 01:43, Vikram Koka <vi...@astronomer.io.invalid>
wrote:

> +1 on this approach with this approach in the PR
> https://github.com/apache/airflow/pull/25542
>
>
>
> On Thu, Aug 4, 2022 at 12:40 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>
>> Love it.
>>
>> On Thu, Aug 4, 2022 at 9:28 PM Jed Cunningham <je...@apache.org>
>> wrote:
>>
>>> Sorry, coming to this a little late. I tend to agree with Elad that we
>>> might be better off not even having 2.0/2.1, and I'll go further that we
>>> should consider only listing main/latest/possibly n-1(e.g. 2.3.2).
>>>
>>> I'm also concerned only showing the latest in every minor may imply
>>> those are all getting bugfixes, while in fact only 2.3.x is. Plus, even if
>>> we tell people to upgrade to the latest 2.2.x version (2.2.5 from 2.2.2,
>>> for example) before reporting, the first thing we are going to ask in the
>>> issue is "what about 2.3.3/main?".
>>>
>>> Another option is a free test field instead, though this doesn't provide
>>> the subtle hint you are after.
>>>
>>> If we don't make it a free text field and don't enumerate all the
>>> versions, we almost certainly want an "other" option? I'd rather give them
>>> that escape hatch then have the wrong version in the easy to spot section
>>> and their real version hidden in a wall of text.
>>>
>>> I've opened this to take your change a bit further:
>>> https://github.com/apache/airflow/pull/25542
>>>
>>

Re: [DISCUSS] Trimming down Airlfow Versions in issues

[Vikram Koka <vi...@astronomer.io.INVALID>]

+1 on this approach with this approach in the PR
https://github.com/apache/airflow/pull/25542



On Thu, Aug 4, 2022 at 12:40 PM Jarek Potiuk <ja...@potiuk.com> wrote:

> Love it.
>
> On Thu, Aug 4, 2022 at 9:28 PM Jed Cunningham <je...@apache.org>
> wrote:
>
>> Sorry, coming to this a little late. I tend to agree with Elad that we
>> might be better off not even having 2.0/2.1, and I'll go further that we
>> should consider only listing main/latest/possibly n-1(e.g. 2.3.2).
>>
>> I'm also concerned only showing the latest in every minor may imply those
>> are all getting bugfixes, while in fact only 2.3.x is. Plus, even if we
>> tell people to upgrade to the latest 2.2.x version (2.2.5 from 2.2.2, for
>> example) before reporting, the first thing we are going to ask in the issue
>> is "what about 2.3.3/main?".
>>
>> Another option is a free test field instead, though this doesn't provide
>> the subtle hint you are after.
>>
>> If we don't make it a free text field and don't enumerate all the
>> versions, we almost certainly want an "other" option? I'd rather give them
>> that escape hatch then have the wrong version in the easy to spot section
>> and their real version hidden in a wall of text.
>>
>> I've opened this to take your change a bit further:
>> https://github.com/apache/airflow/pull/25542
>>
>

Re: [DISCUSS] Trimming down Airlfow Versions in issues

[Jarek Potiuk <ja...@potiuk.com>]

Love it.

On Thu, Aug 4, 2022 at 9:28 PM Jed Cunningham <je...@apache.org>
wrote:

> Sorry, coming to this a little late. I tend to agree with Elad that we
> might be better off not even having 2.0/2.1, and I'll go further that we
> should consider only listing main/latest/possibly n-1(e.g. 2.3.2).
>
> I'm also concerned only showing the latest in every minor may imply those
> are all getting bugfixes, while in fact only 2.3.x is. Plus, even if we
> tell people to upgrade to the latest 2.2.x version (2.2.5 from 2.2.2, for
> example) before reporting, the first thing we are going to ask in the issue
> is "what about 2.3.3/main?".
>
> Another option is a free test field instead, though this doesn't provide
> the subtle hint you are after.
>
> If we don't make it a free text field and don't enumerate all the
> versions, we almost certainly want an "other" option? I'd rather give them
> that escape hatch then have the wrong version in the easy to spot section
> and their real version hidden in a wall of text.
>
> I've opened this to take your change a bit further:
> https://github.com/apache/airflow/pull/25542
>

Re: [DISCUSS] Trimming down Airlfow Versions in issues

[Jed Cunningham <je...@apache.org>]

Sorry, coming to this a little late. I tend to agree with Elad that we
might be better off not even having 2.0/2.1, and I'll go further that we
should consider only listing main/latest/possibly n-1(e.g. 2.3.2).

I'm also concerned only showing the latest in every minor may imply those
are all getting bugfixes, while in fact only 2.3.x is. Plus, even if we
tell people to upgrade to the latest 2.2.x version (2.2.5 from 2.2.2, for
example) before reporting, the first thing we are going to ask in the issue
is "what about 2.3.3/main?".

Another option is a free test field instead, though this doesn't provide
the subtle hint you are after.

If we don't make it a free text field and don't enumerate all the versions,
we almost certainly want an "other" option? I'd rather give them that
escape hatch then have the wrong version in the easy to spot section and
their real version hidden in a wall of text.

I've opened this to take your change a bit further:
https://github.com/apache/airflow/pull/25542