Flint 2 - Where do we file bug reports?

As the title says. I discovered a couple of issues (resolved by accessing Luci) on my Flint 2 router.
How do I report those bugs?

Write a thread here and explain what the bug is, if needed staff will contact you.

Maybe you can share here so that the staff can see it and we may also follow these fixes while waiting for official firmware fix.

Easy:

From the GL UI it’s not possible to configure ranges in port-forwarding. It only allows single ports.

For better results I’ve found titling threads with ‘[Bug] $firmwareVersion: $deviceName ($deviceModel): $subject’ better suited for drawing attention of GL staff & others.

2 Likes

It would also be nice to have some specific bug forum🤔

And then as category the device names with some pinned comments which explain how to troubleshoot / check logs, accessing ssh or scp and how to submit them.

I noticed very often when someone reports a issue its not always clear what the issue is or the user has no idea how to troubleshoot, but i don’t think that is the fault of the user but more a lack on explaination on how to report them.

I’ve been in a few communities, also minecraft ones and bukkit, when they had something like a bug tracker they always had some sort format to follow, and how to get diagnose files.

Then if it was invalid it was invalid or got the tag cannot reproduce, bug if it was valid, dupe if it is a duplicate.

Then it depends of course if a forum is the correct place, maybe Jira is better for bug tracking and trello for pinning todos to let the community know what is planned in a new update.

I think one of the biggest factors is also that the community constantly wants to know what is going to be changed, and often people respond more negative to silence, i think something like Trello can work really well, you can add todo cards on it, that way you can inform the public more and on a vast location, though there is a features topic around here but also for me it took me sometime i found it, so its more a visibility issue i think, but people still think ‘do they listen to me’ as they don’t always see the feedback directly :slight_smile:

That would also make it less stressfull for developers i think when some users may or may not are urging for updates on things.:+1:

1 Like

Hol’on, pawdna! … I’d first just like to see GL get proper tagging/keywords implemented for posts/threads before we discuss go’n hog wild. IMO they really could do w/ a dedicated mod/forum admin first, tech support aptitude second rather than taking time away fr dev/QA just so @alzhao ( ← he’s the CTO IIRC!), @alex_zheng @fangzekun , @hansome , etc. can respond to, in all likelyhood, repetitive questions that’ve already been answered in now long buried threads that no one can easily excavate.

(Side note: I really do like that GL chose Discourse for their forum software; I’m quite taken with it.)

2 Likes

Some of us remember when GL iNet had a public bug tracker:

I wish they would bring it back

1 Like

Hum… I’m not unconvinced Discourse can’t be modded to replicate that same functionality. There’s even a plugin to intergrade pushes to GitHub & other automation.

1 Like

Though i like the idea of discourse too, unfortunately in the past it was idd possible to get atleast some clue on updates via commits on github, but these repos are now privated due to the introduction of chinese firmware and the global firmware so i understand why the git repo cannot be open anymore due to the regulations.

But that also means less to no visibility, thats why i thought trello to be usefull to have some type of road block / task pin system what they are adding/fixing, but this can also be done on a forum idd.

Perhaps there are still some plugins for discourse which can generate commit notes in a:

[Date][Commit][desc]

Format between each release as foot note so it doesn’t even cost much work to type a new pinned release message on the forum, though the commit url won’t work of course because its private, but these commit descriptions are usefull. :slight_smile:

Well, speaking for myself of course, I don’t touch anything that’s not marked stable. I’m not concerned with what’s being baked behind the scenes & wouldn’t expect access to that info… you seem to know a touch about how dev can get stalled. Automating a new release pinned notification to the approp. category for $device would be pretty damn useful. At least one GL user probably has System → Upgrade notifications blocked.

… though such announcements could just as easily be made a duty of a forum admin/mod.

Now excuse me; I think I’ll go back to watch a vidja on a F/OSS kanban/gnatt charts web app. Thanks for kicking me in the teeth on that thought. I’m going to need one sooner than later.

1 Like

I agree. Having some active mod trying to take care of the base construct of the forum could be useful.

About bug tracking: It’s hard to track bugs filed by the community because in many cases it’s just an issue with wrong usage. Real bugs should be at least listed in some thread where nobody is allowed to answer.

2 Likes

Perhaps confirming/replicating the user’s setup/issue can be a part of said mods duties before escalating it up to devs or marking it the aggravating Works for me: WONTFIX.

I am not sure if I would agree about the “duties to replicate issues/setups”.

Speaking for myself: I’ve done this a couple of times now because I was interested in the technical difficulties - but at last, it’s a very time-consuming job. What’s more, there are major geographical differences. While I can say “it works for me” for some things, it may not be testable for others. (Example with the DHCP 60/61 problem with Sky ISP)

I would therefore separate forum moderation from first-level support. But it also depends on how big GL is overall and whether they have the man/woman power for it. You could also think about handing over forum moderation to particularly active members of the community.

I’m looking at you, @bring.fringe18


And while we are speaking @Summer shows up and seems to do some community service :wink:

2 Likes

Ya know, I had that exact thread in mind when thinking about what’s a reasonable for another on the other side of the planet to be able to do. I had more in mind of being able to read logs & know what conf needs what where &/or how uci generally works when the GL GUI/LuCI won’t/is limited. Knowing basic tcpdump never hurt no one.

Being able to take a set of a user’s WG Server/Client of confs &/or knowing how to add feeds/repos &/or know what GL script needs more params added to it for whatever reason shouldn’t be something completely beyond 'em, off the top of my head & for example. I would think the mod is going to have to a strong, strong sense of technical skills such as knowing differences in firmware beyond just reading a Changelog & not being afraid of getting ‘under the hood’ in OpenWrt.

Technical comprehension/writing is a key factor to a well structured forum/knowledgebase, if not all the more so in importance given the nature of these embedded Linux devices, IMO.

/ 0.02USD

2 Likes

I think need to make a pin thread/post about known bugs and process investigate by gl-inet staff…

1 Like

This is more like a feature.
I didn’t find a similar one here.

I’ll forward it to PM, they will evaluate the dev plan.

1 Like