Bug reports to be tracked/tagged by @Jolla

Bug Reports
1

REPRODUCIBILITY (% or how often): most often
BUILD ID = OS VERSION (Settings > About product): does.not.matter
HARDWARE (XA2, X10, X10 II, …): does.not.matter
UI LANGUAGE: en?
REGRESSION: (compared to previous public release: Yes, No, ?): no

DESCRIPTION:

Reported bugs here cannot be recognized as seen/worked on/solved…

PRECONDITIONS:

Report a bug to this forum.

STEPS TO REPRODUCE:

  1. create a new bug report

EXPECTED RESULT:

the bug report gets noticed by a sailor
it gets an answer
and at best a mark/tag/answer that it is not reproducible / notified / being worked on / solved…

ACTUAL RESULT:

…

ADDITIONAL INFORMATION:

(Please ALWAYS attach relevant data such as logs, screenshots, etc…)

6 Likes
2

IMNSHO, this should be brought up in a Community Meeting, not raised as a bug, because it isn’t a defect in Sailfish OS.
FWIW, bugs reported here get a lot of attention from Jolla, and they have an internal bug tracker.
Try Google, Apple, see if you can even identify an individual behind their corporate walls.

5 Likes
3

I don not think bugs should be “modified” by Jolla, i.e. the original bug report should stay untouched (by anyone but the original reporter), but rather “tagged” to reflect the status in Jolla’s internal bug tracker, as Jolla did at TJC, preferably with a few more states.

In short: It would be really helpful to know, if a bug report has been

  1. read
  2. understood
  3. technically traced
  4. acknowledged to be a bug worth fixing
  5. worked on
  6. fixed, but not yet deployed
  7. deployed in a SailfishOS release

or

  • dismissed (after any of these steps; i.e., step 1 is mandatory to carry out and document)

by Jolla.

8 Likes
4

I fully support olf’s point! It is important for reporters to know that their efforts to pinpoint and describe the problems were not in vain.

3 Likes
5

Agree that comunication in this area can and should be improved.

And also agree community meetings are the place we should start at. Maybe schedule a topic/question along these lines for every one of these.

Or, maybe that could be a new section in the Comnunity News?

I doesn’t have to be elaborate either, just a list of ‘this has been acknowledged’ would suffice for a start.

2 Likes
6

I cannot concur, because Jolla stated that this forum is the place to address and discuss any issues and many cannot participate at Jolla’s “community” IRC meetings.

2 Likes
7

I do suggest to not use this forum to track bugs. Its not for such usage. Despite that Jolla said that https://bugs.merproject.org/ will be closed, it also said that https://github.com/sailfishos/ is more appropriate and effective to post bugs as issues against specific projects. The problem that i see right now is, that the “issue” tab is not enable in all projects at github.

For example:

versus

Sure, you can do a PR but this is not a bug report.

1 Like
8

I’m not talking about moving bug discussion to IRC, but starting a conversation how to improve feedback on bugs. At a community meeting.

1 Like
9

I get your point, but that’s way too detailed to work in the long run. Ticketed / fixed / released would be plenty, with additional “won’t fix” or “that’s a feature” comment :slight_smile:

But yes, this is a matter for community meeting.

10

@leon, I suggested that multiple times (to open the issue tracker for all “projects” at github.com/sailfishos/), but Jolla dismissed that repeatedly.
Which is awkward and inconsistent, because a few “projects” have their issue tracker on, as you observed.

Nevertheless, by using SailfishOS one more or less is bound to obey Jolla’s rules (though they are a fuzzy and moving target) and hence primarily file bugs at FSO.

P.S.: bugs.merproject.org seems to be dormant (for a while, already) and not maintained any more (at least not by Jolla).
Plus bugzilla is fine for tracking bugs for organisations (companies etc.) due to providing many meta-information fields for that purpose, but not end-user friendly.

11

So @nephros / @direc85 is one of you taking it there, i.e., scheduling this topic for the next IRC “community” meeting (that has to happen today or tomorrow): Community meeting on IRC 25th November 2021 ?

I (and likely @Peterleinchen, too) are not going to defend this proposal there (for a couple of reasons).
Still I would rather see such things consistently discussed at a single place (i.e., here, in lack of a better one), but do as you like, as long as you believe it raises the chance of a positive outcome.

1 Like