Difficulty of bug submissions

Who says you have to be a developer to login to GitHub? And why generalize this specific issue by mentioning Codeberg and SourceForge? HaikuPorts is on GitHub, so let’s stay focused on that. Yes I do understand that using GitHub is somewhat controversial nowadays ( I have moved my own projects to Codeberg, but still contribute to projects that are on Github).

So you have to make a decision: If you want to reports issues to Haikuports and therefore help to get them fixed, you have to get on GitHub. Period. If you dont, that’s OK too.

Sometimes I don’t understand stuff like this: Open source developers are creating amazing software in their free time (mostly) and some users are too lazy to create an account on a website to help report bugs. Again, I understand people not wanting to use certain websites because of privacy concerns, political/ideological reasons etc. But laziness doesn’t count. You get a whole OS and lots of applications for free, so you surely can spend 5 minutes to report a bug.

Sorry if this turned into a bit of rant but sometimes I can’t help it :wink:

5 Likes

No,as Begasus offered to mirror issues that are created on Codeberg.
What I don’t understand is people trying to force users to register with specific questionable third-party services and thereby create vendor lock-in.
Really,it drives me crazy everytime someone mentions it.
Yeah,Codeberg is a single centralized instance as well,but at least it’s open-source and owned by a non-profit rather than Micro$oft.

People often write bug reports here on the forum,and always someone who already is on M$ Github sees it and tries to force people into the M$ walled-garden.
Why not just copy the bug description and create issues on behalf of that user then?
Even better in my opinion would be a email address to report HaikuPorts-specific issues to,then you don’t need to register anywhere,just write a email and that’s it.

Yes,and many people are reporting bugs here.
We should be thankful for people pointing out what needs to be fixed,rather than crying that they did so at the wrong place.
With my own projects,I’m very flexible with that because I don’t want to force people to any specific platform.
My source is hosted at Codeberg where you can create issues,but you can also reply at my forum topics,write me a forum private message,write me a email or mention me in the #haiku IRC or wherever else I see it.
What I want to say: Be thankful that users try to help and be more flexible where they do.

2 Likes

Too lazy to accept the risk of yet another account they have to remember a password for, have to secure and deal with? How long does it take you to read the TOS of the github? Did you check?

(For most websites this takes from 1h to severall days in my experience, especially with spaghetti “oh this btw also applies style TOS”)

2 Likes

Github themselves, on their homepage when you don’t have an acocunt:

The future of building happens together

Tools and trends evolve, but collaboration endures. With GitHub, developers, agents, and code come together on one platform.

If you are not a developer, an agent, or code, then Github is not for you. I think they’re right (for once), and people using Github for anythinfg else (such as user support) are wrong.

This attitude seems wrong to me. People should not need to create an account on a closed source platform to work on open source software. Users should not need to deal with a tool meant for developers.

Or maybe, some users are trying to report bugs and developers are too lazy to set up appropriate tools to handle such reports in an helpful way.

Or maybe, both users and developers can work together, and not fight against each other? Wouldn’t that be better?

You get users doing your testing and QA for free, you surely can spend 5 minutes to record their feedback in whatever tool you decide to use yourself as a developer.

I strongly recommend that you reconsider how you view “users” who are in fact your QA and testing collaborators in an open source project. And when they tell you you should improve your community management, you should consider that as well. Otherwise your project isn’t going to work well.

5 Likes

Yeah that’s great. Let’s see how it works. I’m happy if it does.

I’m not advocating for any of that. I simply stated how it is at the moment (or was until recently, considering the new codeberg mirror). And I explicitely stated that I understand people not wanting to use Github. But the poster I replied to didn’t mention any of these concerns.

Again, see my reply to @nipos. The poster I replied to did not mention any of these concerns and I explicitly stated that I understand people who do so. And no, I did not read the TOS. What good would it do me, since I’m not a lawyer?

Yeah, one point for you. Great. But seriously how hard is it to open an issue on GH. Do you really have to be a developer for that?

Fair enough. I actually agree with you. I didn’t advocate for that I simply stated the status quo. And again, nothing in the post that I originally replied to indicates to me that the user worried about these things.

Personally I don’t do that. Except for people from countries that are banned from that platform in question. But it’s completely fine if you do. If that means that I should stop telling people to open tickets if they report bugs on the forum then I will do so.

Thanks for the recommendation :wink: Actually, so far nobody complained. But then again my own projects are quite small and don’t get that much contribution. But I value the few contributors very highly and tend to get along quite good with them. So, thanks again for your concern.
As far as Haiku is concerned as an OS, I actually am a user. That’s also mostly true for HaikuPorts, apart from a few contributions, mainly the recipes for my own apps and a few bug reports.

Sorry for the long post and for further OTing this thread.

1 Like

While I offered creating issues on my codeberg repository, this should only be used for people not wanting to deal with GH, the officiat issue tracker will remain there untill otherwise decided.

Not promising great deals, but maybe that little effort could help out. PS, not sure if you need an account on codeberg to create an issue, if it does, it doesn’t differ (on that account) then GH. :slight_smile:

1 Like

I think that the problem is bigger than that.
Honestly as a simple user point of view, it isn’t always easy to find where to report a bug.
Most packages are in Haikuports but how many are knowing BeSly tracker address? Is there even a tracker for LOTE packages? And more we will have native packages more we will have trackers.

To help further, lots of packages in HaikuDepot are linking to the website of origin. That’s nice for doc eventually but sometimes it also goes to limbo. So, I suggested here to add a second url to packages so you could indicate the tracker but it doesn’t seem that easy.

But a better alternative would be to have an unique app tracker that would dispatch bugs to all repositories and that you can join from HaikuDepot. An unique user account to log in, it would make that very cool. I mean an account where you can select sites to opt in or not. Two quick options, either developer and access to all sites including Gerrit, GitHub etc or user with only access to the forum, to the two trackers, to HaikuDepot to review and give a note on packages and perhaps to IRC. Of course, if you evolve from user to dev you should be able to modify the list of sites that you have access.

Maybe the HaikuDepot app should have a “report an issue with this package” button that would add the report to the HaikuDepot web site and send the report to the port maintainer?

It’d be work, but what wouldn’t? :slight_smile:

I’ve only done one port so far, but I’d be fine with receiving an email if someone has a problem with it and then clicking a checkbox on HaikuDepot’s web site to say whether I’d addressed it.

2 Likes

I really like that idea :+1:
Yes,it would be work,but it would make reporting bugs much easier for users,hopefully resulting in bugs getting caught easier and faster.

The problem to those alternative options is that they do not contemplate any further discussion about the ticket: what if the developer asks the user to test a new version? or need additional information about the issue? The “create a report issue with this package” only is useful for a “fire and forget” approach to submit bug reports.

Send the users email address with the ticket,then the developer can reply to that email address asking for further information.
Maybe there could even be a public page where this issue communication can be shown,but I don’t think there’s a need for a centralized platform where one needs an account.
Email is already here,it works rather reliable and almost everyone already has an email account.

By mail? only feasible if you have only one (or two) developers, and the issue did not require much “discussion” about. Again, is possible for small and simple projects. But imagine HaikuPorts, where there are maybe 400 open tickets.

Again,there can be a public page where those discussions can be viewed and organized for other developers to follow the discussion.
This doesn’t need to matter for the user.
The user cares only about that single ticket they created and can follow up the discussion by email (which then gets recorded to the ticket portal).
Well,such email ticket portals already exist.
I think they’re quite common for internal use in big companies (the company I work for also uses something like that for IT stuff) and work well with big numbers of tickets and users.

I’m pretty sure most of the ports only have one person who did the port; port recipes are reviewed (oh, they are extremely reviewed :-), but I doubt many have substantive non-review work done by more than one person.

I could totally be wrong about that.

This would be a change for haikuports, since right now their system doesn’t have a “port maintainer” concept like some of the BSD ports systems do. But it’d help spread the load of dealing with trouble reports away from the maintainers of the ports system, which is probably desirable anyway.

For example, I ported autossh last month because I wanted to use it; I figured other people might want to as well, so I wrote a haikuports recipe and submitted a PR to their github. They reviewed it, I adapted it to respond to the reviews and they accepted it.

I think it’s reasonable that if anyone has a problem with the port, that the report can be sent to me since (at least in theory) I should be more familiar than anyone with the details of the port and I don’t mind accepting the responsibility to fix any errors I may have made (or pass reports on the the actual author if they’re not specific to the port).

Again, though, that would be a change in how haikuports operates and it’s up to them if they want to do it.

It depends on each project really.

For something large like Haiku, we need a quite complicated bug tracker like Trac, and we will help users register there and create their ticket so they can receive notifications.

For many of my smaller projects I’m happy to receive support requests by email. For some of them I didn’t even bother setting up a bugtracker.

That’s what makes it difficult to handle at haikudepot level (and also for users in general): each project will have different procedures. Unless haiku/haikuports starts adding an intermediate layer on top of that. Something like Debian does, maybe: they have a “reportbug” command that asks the user a few questions and then sends a mail to their bugtracker mailing list, with the user reporting the problem in copy of the bug. But that means extra work for haikuports (or for the bug reporting tool?) to coordinate things and forward the bugs to the right place if needed.

Maybe for small projects only an email sending/notification should be fine.

Bug tracker should make more sense for huge projects (in term of how big is the source code) but indeed the tool will depend on each project. Trying to unify this kind of tool is not very easy I think

Thank you, @Starcrasher – this is what I offered in my original post – I just had not express more about it

I do not know ii it would be capable to fill up the the mentioned tools’ fields or just send a message that the maintainer find the details in this webapp instead of his mentioned official issue recording place I do not know that yet : which is easier which is better. Also I would not decide that.

I just would like to have a unified reporting place for Haiku applications - especially that is just for that. Github or any such service is for many things - me myself I intentioally had not mentioned the firm which owns that service as I totally do not care but the Github surface to use. As a software versioning thing possibly quite fine possibly, moreover in the command line - but as an end user the web interface is a total mess. At least for me. I just used it rarely to get some single files from there - like youtube.lua for vlc and some smaller developments and it was more years I could find out it is more simpler to get files if I have git and clone it, than to download via download or copy the text into a text file as some instruction suggested.

I assume it is easy to use as if you use it daily to deal with - I do not do that. Also I had not wanted to deal with such way. I imagine a lesser experienced user how would be happy to try to find reporting place and report there.

I assume may more users would come - some here always hoping crowds (sic!) - who would not know the Haiku related services .. especially related to applications Haiku. Haiku apps delivered with OS differs from ported apps, apps from Haiku archive .. etc. They just want to report. And as there is much easier to report actually on forum - they do.

I am not lazy -

Sometimes I solve my problems alone, using my skills if that’s enough.

Sometimes I do not report as I cannot provide evidence. There is no option to create a saving of KDL messages - at least I do know, and had not found or read such command.
I do not have a camera or phone to record it readable. My phone’s cam makes garbage like in the ‘90s or worse.

I had bfs kernel panic - solved with refreshing EFI bootloader
I had FAT related KDL on Haiku nightly recently when I wanted to copied between two Haiku ESP partition to refresh the bootloader on other thumbdrives too. Solved as mounted them on Linux Mint and copied the files there.
Some hrevs before it was possible to mount and copy the files between them but then on targets the files showed size 0. OK I thought it will be fixed soon - it was done so, as it was nightly.

I am not lazy, but without tools or sometimes with knowledge to solve it with workarounds - if possible.

I hope in the future I can save KDL messages in a way, and there would be a unified place to report issues with applications on Haiku - not for me, but for the community. Consider with new members.

So, if haikuports added some new variables to the recipies like:

  • PROBLEMEMAIL
  • PROBLEMURL

Then HaikuDepot could add a “Report Problem” button that could open a web page (if PROBLEMURL is defined) or an email (if PROBLEMEMAIL is defined) or open the haikuports issues page on GitHub if neither is defined?

(And probably log a copy of the reports somewhere as well, since sometimes folks disappear after doing the initial port and won’t bother responding to problem reports.)

That would route problem reports to the most specific and appropriate location and let each port specify how it wanted reports handled.

BTW, I guess in order to push MR on HaikuPorts, one still need to do it from a project hosted on Github, right?

Or is it possible even from a git repo hosted on codeberg for instance ?

Right, one can’t create a PR from Codeberg to Github.