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 <elad...@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.
