Can I suggest GL-Inet setup a bug tracker?
It would be much easier to find and track bugs and subscribe to them to be notified of fixes.
@alzhao @kyson-lok I vote for this too.
It would be great if GL sets up a bug tracker so we can post our bugs, and also see what is being worked on in the background. When a bug or feature is being worked on internally, it can be added to the bug tracker so we can see the progress too.
Do you have a recommendation of a lightweight and easy to use bug tracker system?
OpenWRT uses Flyspray:
I saw that. Looks much better than bugzilla.
There is also trac. Unfortunately both flyspray and trac and even bugzilla are not fully integrated, they need the webserver and so on configured separately, so not like this discourse forum system that is fully integrated.
MantisBT is pretty sweet. It’s the equivalent of this forum lets say, with Markup and lets you post images and so on.
Take a look:
I think it makes sense to use the GitHub issue tracker associated with the imagebuilder repos.
Make a pinned post in the software section. List all the models of the same hardware type then link the various imagebuilders and their associated issue trackers.
Something like:
| Supported Model | Software | Version | Firmware | Links | Notes |
|---|---|---|---|---|---|
| AR300M AR300M-EXT |
GL.iNet | 2.27 | GL.iNet NAND |
NAND Image Builder NAND Issue Tracker NAND Wiki |
Latest Version |
| AR300M AR300M-EXT AR300M-LITE |
GL.iNet | 2.27 | GL.iNet NOR |
NOR Image Builder NOR Issue Tracker NOR Wiki |
Latest Version |
I think using a dedicated bugtracker would be better.
GL will be able to set up road maps for release of routers and firmware also, apart from bugs and features.
The UI of the routers is not open source, so it would be strange to have bug reporting for the UI in one repo, and then bugs for each imagebuilder too…
I think it would be best to put it all in one place. GL will be able to internally start using the bug tracker too, instead of the solution they are using at the moment. Their developer team would not want to be using github for reporting progress i don’t think, and like above there would be too many urls and so on to keep track of.
Good points. I was just going for the path of least resistance. A lot of people already have GitHub accounts, and the issue tracker is already there, no need to set one up, host, care and feed it.
If you want to go that route, FlySpray seems good. If you’re going to set something up though, go for a GitLab instance, get the full build system going with build releases and the bug tracker, wiki etc. Or pay for SaaS GitHub/GitLab. 