Late in the F36 cycle, a number of issues we found in gnome-calendar - see #304. They were:
It would be good for the working group to conduct its own evaluation of gnome-calendar - we should test it and keep a record of any issues we encounter, and then have a conversation in the context of #304:
Metadata Update from @aday: - Issue tagged with: qa
Metadata Update from @catanzaro: - Issue assigned to catanzaro
Are you planning on conducting your own review, @catanzaro ?
I've reported a lot of issues upstream. The issue tracker here is in concerning state. Calendar has nearly 500 open issues. It looks like nobody is triaging incoming issue reports.
What are our quality expectations for the app?
It should pass a basic functionality test. Calendar management should generally work. Users should not encounter obvious bugs.
Does the app meet our quality expectations?
No, based on the issues discovered above, it does not meet our expectations.
What kind of issues should be classified as release blocking?
Basic functionality issues. I'd vote to be stricter here than we would be for other apps. The calendar is an essential application, and if it is not working correctly, our users will miss meetings and events. E.g. we shipped for years with this bug where events display at the wrong time. I would have blocked Fedora release on that due to its severe impact.
Is there anything that can be done to increase quality?
I'd say top priority would be to triage upstream issue reports to get the issue tracker into a manageable state. Maintaining a quality application is impossible if the issue tracker is out of control. Unfortunately, due to the high number of untriaged issues, this would require considerable effort.
I've done some cursory testing on this app today.
Superficially, things look pretty good. The main window looks nice and has recently had a UI refresh. I can see my events from my Google calendars, and I can add and remove events from those calendars.
But I was able to reproduce one of the issues in the original report here: if you create a bunch of test events, then delete them one at a time, then close the app, they don't seem to be fully removed when you restart it.
Yesterday I deleted all instances of a recurring event. It disappeared only from the current month and not from other months. When I restarted Calendar, it eventually disappeared from other months.
Sometimes when I change date of event from one month (let's say, current) to other month (let's say, next month) the event is shown is both places for some time: a few secs and a few switching between two months views. The change is not immediate and looks buggy from UX perspective.
We discussed this issue during today's working group call. The consensus was that we'd like to keep it in the default app set for now.
While Calendar has known issues, it has also improved recently. It would be good to continue tracking serious known issues, in order to ascertain whether they are getting fixed or not.
Another release has rolled around, and F37 saw another round of gnome-calendar blockers turn up.
The view from QA is that Calendar likely has many potential blockers, and needs exercising through dogfooding to find them all.
It would be good to do another, more serious round of evaluation during the F38 cycle (ideally early on).
Metadata Update from @aday: - Issue set to the milestone: Fedora 38 (was: Fedora 37) - Issue tagged with: pending-action
@kparal tested Calendar for the F38 test week and linked to the following issues:
Issues with fixes:
Currently unresolved:
It doesn't seem useful to keep this issue open. If we want to return to the question of GNOME Calendar quality, we can still do that.
Metadata Update from @aday: - Issue close_status updated to: Won't fix - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.