I didn’t use the stock Mail app for a year anymore … for reasons.
But I made an issue (/e/ was 0.13 then): the Mail app doesn’t survive a Flight Mode.
Yesterday I got a message from GitLab, the issue has been closed, the last comment tells more about the reason:
This issue has not shown any activity for a while.
It may be outdated or may have been fixed by a new release.
If you think that this issue is still relevant you can reopen it
and post a comment to provide updates on the topic.
Now you know it: the issue, this idler, has not shown any activity.
I open an issue because of a serious problem, the issue is then confirmed by others who also have it, the issue gets at least two milestones (0.15 and 0.20) but remains still unsolved for a year, and is then declared as dead. This is as good as solved as long as nobody contradicts. – What ridiculous kind of issue management is this? And who else will still open an issue knowing that?
Nevertheless the problem is still there. I checked it this morning because it’s very easy. The damned Mail app does still not survive a Flight Mode (at least this was the test result on my device). This could also have been recognized by someone else if there would be one who has really an interest in this and some kind of responsibility. I told exactly how to reproduce this. – Doesn’t matter at all. The entire problem and the user do not matter at all.
Murena has a serious problem here. I call their issue management unprofessional.
This is due to a script that is now being run in Gitlab on issues which have seen no updates for some time. A number of issues get resolved with changes upstream or through developer merges. Ideally, each issue should be tracked to closure with comments, but that is not happening or always possible. You can always reopen the issue if it is still relevant.
" Arnau Vàzquez @arnauvp · 1 year ago Owner Actually, this has starting working for me after upgrading my FP3 to 0.18-q (stable). Might be just luck or unusual combination…"
(Owner = “This user has the owner role in the Backlog project.”)
I do not think you should consider yourself an “idler”, but my first reaction was that I felt this was good management of 1347 open issues I see that /e/ robot · GitLab was “nominally” responsible (I had a couple of emails from him this morning!).
Testing self built v1.4 I see Mail is v6.303 as against v6.301. Flight mode is not mentioned directly in the “What’s new” feature (= the Mail release notes) but perhaps /e/rebot was optimistic, hopeful or knowledgeable in saying “may have been fixed by a new release”
May be. But running a script which closes all issues having no activity in a given time is not good at all. A script is always a no-brainer, ist has no sense of responsibility. It kills - I’m sure - a lot of interesting issues. This means these problems will remain in many cases and still mither users. A closed issue is dead and never seen again.
I would prefer if someone who solves an issue would also have a look on other related or similar issues and closes them with a link.
And what’s the consequence now? Am I really responsible for any “activity” in the issues I made? Just to outfox this script? Nobody asks why there are cases open for a year.
I would agree with you, if this was generated by a script, idk, but when signed in I think you can very simply reopen (it is only a #tag after all) and ask if v6.303 actually fixed the issue, or if you feel like being less noisy wait and test v1.4 then report either way.
Some noisy contributors have been known to comment at every release, or until they get used to it.
I think this is very common practice to avoid real humans wasting time on endless lists. Most people are lazy, e.g. never report back, if something is fixed at some point. They only get vocal if something is not ok.
When nobody affected by the issue cared for a year I’d say it’s dead for good.
If it really is important to you: just reopen it.
Don’t get me wrong, I can understand the frustration if something doesn’t get fixed soon enough, though.
