That’s really awesome material thanks @ben79
I’ll be quite busy today but will be able to continue discussion very soon.
1 Like
I’m busy also. Election day in US for one and some other stuff going on this week and next. So we’ll get done what we can and someday we’ll both have time to do more.
I believe it was @rugyada that suggested we table this effort until at least OM Lx 4 Alpha is released as there is a lot of work to do on that. I’m in agreement on that. I keep meaning to get back to this and things keep coming up.
There is a category of bugs that I would like to see if we can find a better way to support. These typically involve laptop/notebook users with some functions not working but are not exclusive to only laptop/notebooks. Another example is some of the less common graphics hardware. These bugs are difficult or impossible for our developers to resolve partly because we have no way to reproduce the problem. I don’t have any answer for these at this time myself but we could use some ideas and creative thinking on this.
Some laptop examples:
Touchpad not working on a Lenovo 320 14"
https://issues.openmandriva.org/show_bug.cgi?id=2284
Display brightness not working on a Lenovo 320 14"
https://issues.openmandriva.org/show_bug.cgi?id=2285
There are others and probably sometimes similar issues on desktops as well.
A recent example of the graphics type of issue. This one was solved but might never have been if on of our own @AngryPenguin didn’t have the bug and the hardware to test on, and, this is important, @AngryPenguin was very persistent in seeing to it that the issue was not forgotten.
Cooker ISO does not boot on r600 with old CPU
https://issues.openmandriva.org/show_bug.cgi?id=2381
The best thought I’ve had is we attempt to get people with such bugs to go on IRC and engage directly with our devs. And they would need to wait until someone has time to work on their issue but at the same time be polite but persistent about their issue not being forgotten.
It is perfectly OK in my opinion for us to suggest to users how they can help us better to help them with their issue. Anyone with ideas on this let us know because that is the kind of thing I want to get in our “Support” documentation.
Is it time to continue discussion on this topic, or too soon and we wait OMLx 4 is out?
1 Like
After OMLx4 is out. I’m buried at present.
Sure no worries, let’s postpone it.
1 Like
Let me jump in into this…
If we want do an move on issue tracker need be done before Lx4 final not after.
I’m honest , I do not like bugzilla to much … Is not the best issue tracker out there , stuck in the 1990’s 
Howver out-sourcing issue tracker is not such a good idea.
I like github way of having custom labels etc but there are strange things too.
You cannot really control to much there , sure you can lock topics etc but that is about it.
So does it need be github or does it need be something to be able to do some
forums < → issue tracker tricks ?
2 Likes
If that is the case then we need to get on this right now whether I’m busy or not. It can sometimes take some time to get people to agree on switching something like this. If we decide to switch.
As far as I know no one is a big fan of bugzilla and no one minds changing from bugzilla. What is not clear to me is what is better.
Bugzilla seems purposely designed to be “old fashioned” or “stuck in the past”. From what I see Github is better in some ways and worse in others.
If not Github then what?
Unless I learn something I don’t know today my stance is if devs prefer Github we switch if they don’t we don’t. As for other options I simply don’t know.
The other part of this project I was wanting to do with @raphael And @abucodonosor and anyone else that wants to participate is simply writing some wiki documentation for how we manage issues and bugs. That I think we could get done in a week if we work on.
So @raphael I’m changing my mind on this. Let’s get started on the wiki stuff. The issue of change or not change of the issue tracker we should first discuss if there are options better than Github or Bugzilla and go from there.
Regarding Github we set up a Kanban board for OM Lx 4.0 Alpha development that no one uses so all those ‘neat’ Github features don’t seem impressive to me if we aren’t going to use them.
So to get started:
-
Do we want users to report absolutely every issue as a bug report?
-
For our purposes is there a difference between an issue (for instance: one user having a problem with their computer) and a bug (a problem or flaw in the software).
-
When is it appropriate to file a bug report and when is is appropriate to report an issue on the support forum? (Depends partly on answer to question 1.)
Yes we want.
That depends … But is not really a difference from ‘is a bug’ part.
Lets take Nvme SSD M2 not seen by OMLx 4.0
as an example.
User faces ‘kernel bug’ while broken HW… And indeed the HW is bugy however in this
case we fixed with a kernel patch.
There may be cases we cannot easy fix some things , but these are still bugs.
Usually forums is not the place to report bugs.
There are corner cases to discuss workarounds for say closed source SW but the report
should still exists in our issue tracker.
There is no way to follow random reports in all the forum thereads and developers will for sure
miss some reports but that is not the real issue.
With random issues reported into the forums we have no way to assign , plan , document
changes and fixes are done to fix these , assuming we see the bug reports.
Really , even ‘Hey guys in my menu some application is missing icons’ is an bug
and need fixing.
1 Like
Could https://taiga.io/ be a solution? I know that it’s linked to github and similar, and does even project management. Maybe @bero could tell more as he uses it.
1 Like
That approach works for me. I’m simply looking for a system that works and is not overly complicated. The hope is for a system that is consistent and that all of us can and will follow.
And I want to get some documentation in our wiki but the goal is the same, simple, understandable, and not to long.
-
So one page for user: Have a bug or problem with your OM system? Do this.
-
For QA and developers one page I hope: These are our policy and procedures for support.
-
For QA and developers one page: Here’s our support workflow.
Post-edit: Existing documentation:
btw we can have own ‘github’ that include all repos ( for now as a mirror ) and
sometimes the other way around , github being a mirror.
We run gazillions containers one more with say gitea/gogs and there we go ,
‘github’ like issue tracker , fully under our control + bonus for repos etc .
1 Like
I think I get your idea, but I’m not sure @abucodonosor, do you mean we should use github page only as an archive?
Later as a mirror , mening you push to own repos and mirror to github.
So we have own repo = 100% clone on github , what again means no matter which one
fails one is still working., unlikely both to fail the same time.
This is easy to do with just some git hooks.
1 Like