I was wondering if there is any major reason why Haiku has a GitHub mirror but never moved to GitHub over the course of years.
I understand that current contributors are used to the existing environment and for them it would imply changing their workflow for very little or no benefit, but it always puzzled me anyway.
And it somehow resonated. Trac was developed and designed by developers 20 years ago, so the UI isn’t very welcoming and the interactions are not natural, so I understand that sense of “I won’t do it because it needs me to deal with Trac” for a new contributor.
As I can see the benefits of moving to GitHub (lower entry barrier for new contributors, no hosting to manage, more exposure to the community), I was wondering what are the downsides that the Haiku team has seen so far and that kept the project in its current infrastructure
Please, no!
We were even talking about moving Haikuports and other stuff to own infrastructure, unfortunately without results yet.
Github is a proprietary walled-garden owned by Micro$oft, our biggest competitor.
I don’t have an account there and I know there are others in the developer team who don’t.
Free software shouldn’t rely on non-free services for development, as this locks out those contributors who believe in freedom the most.
I would definitely leave if forced to proprietary stuff.
I’ve already quit contributing patches to a lot of projects because they’re not responsive in any way outside of proprietary platforms.
Controlling where software is developed and who is allowed to develop it is the biggest victory M$ could possibly have over free software - but is it still free software then?
I like Trac, it works great here and I’m sure that you can also get used to it if you try it.
If it really turns out to be a suboptimal choice in the future, we should better talk about alternative free software solutions like Forgejo or Gitlab that we can self-host instead of Trac, but a proprietary M$-owned walled-garden is absolutely the worst choice of all.
I, for my part, think that Trac is a great choice and we should stay with it.
Personally I don’t have a github account, and do not want one. When I had one it was not pleasent to use.
The current workflow for working on haiku is this:
Clone the repo (one-time)
install the commit hook (one-time)
commit your stuff
push it to code review
ammend commits based on review
push again
While on github it is (afaik) something like
clone the repo (one-time)
make a fork (or do this first) (one-time)
change branches on local fork so you can pull from right repo, but push to the othrt (one-time)
develop your changes
push them to a specific branch to your “fork”
use the webUI to make a pull-request thing, adding additional stuff
Add new commits based on changes, or force push but destroy the review part
either squash or ask for a merge
(all while keeping in mind where the info even is you need, is it on the original repo? is it in a pull request discussion? in a ticket? as a comment on a commit? As a comment on a commit that is not inside the original repo?)
To me the workflow of github is just so much more work, especially having to use the UI to create a change in the first place, that makes no sense to me.
I’d like to play a bit devil’s advocate here, do you want an extremely low bar to entry? In a project like an operating system we always will have a somewhat high bar for entry, expecting people to read the bugtracker etiquete before reporting a bug, expecting to read the code style before opening a change, etc.
Even on the github mirror it sais “pull requests are not accepted”, but somehow severall pull requests were opened regardless, since that text was not even read.
Anyhow, personally my #1 reason is not beeing tied down to any microsoft owned software or auth service. As for the aspect of there beeing a lot of people with github accounts already, you can login to our SSO with github, and use those credentials to push stuff to the code review if you want.
Currently this is not hooked up to trac and the forums, but it should be in the future.
One additional aspect for me is that I am one of the people who maintain HaikuWebkit (the port of webkit for our browser), and I am annoyed that github keeps depending on new stuff without checking if it is supported and then spams the console log (spinning up a core to 100% for this). But that is just my personal annoyment of the service, currently the UI does not work great in WebPositive in general in my experience.
Edit: as for the mastodon post, well, that is unfortunate. and the SSO should help in the future: However it does not change the expectation of the bug tracker that the user would be available to test if the bug is resolved in the future. So if your ticket or pr is “only” a drive-by, without any intention to work on it in the future that may be more hassle than it is worth (for the project)
Every change on GitHub is done to treat people like bloody infants. 2FA is just a retarded function to force. I hate how Steam forces it, and that’s just for video games, something trivial for entertainment. I can atleast understand it since its often targeted by combolist script kiddies and Steam users aren’t expected to be tech litterate, but GitHub? It’s a service meant for developers. If the account is high-value then it’s the user’s responsibility to have a secure password. The only thing 2FA does is making it that the user gets depended on multiple services. No phone with you or forgot the password of your mailbox? No luck. The only thing a good service actually needs is a username and password. It’s just taking away choice.
GitHub has a too big monopoly on open-source software development just because it’s the standard.
It may be worse then Discord and its horrendous walled garden with verifications after verifications. All the while actual open source services like Matrix exist which are even more accesible then Discord and is more appropiate for open-source projects.
Can agree with OP Mastodon post, it shouldn’t require an account with e-mail just to share a bug.
As a simple user, I can say that GitHub bug tracking is poor. Reporting some bug in Haikuports issues can seem easier but when you’re looking if something similar was already reported, it already shows its limits. It is far easier on Trac where you can search by component, for example.
It could be that, through my user vision, I don’t see advantages of this system. I hope there are some.
But, if something had to move, I would prefer Haikuports bug tracker elsewhere. A place that allows users to login with same credentials than they use for Haiku bug tracker would be nice. I would even say, both trackers should have same look and only different colours.
Still, we own big thanks to all of people involved and active at GitHub bug tracker; without their reactivity and silent hard work, Haiku wouldn’t look so good.
Github is closed source. Why would we use a closed source tool owned by one of our competitors (Microsoft, who is making Windows) when there are perfectly usable open source alternatives?
GitHub doesn’t have subcomponents to triage issues. In fact, it doesn’t even have components. And, since it is closed source, there would be no way to add that (as we did for Trac: the subcomponent extension is maintained by Haiku developers). With Haiku having several thousands of issues, this would be unusable for the existing developers.
There are less developers than there are users, and so, we need to make things work efficiently for the developers first. Yes, that means the bugtracking tool is not super user friendly, and that you have to create an account to use it. But, if you just want to report a one-off bugreport, that is easy to do, here on the forum, by email, or you could send a message to the Haiku account on Mastodon, and someone can then immediately fix it (if it’s a simple thing) or create the ticket on your behalf. Haiku is a project run by humans, who can handle such flexibility, and you could use that.
Maybe when thousands of users start doing this, and the work of entering these tickets onto the bugtracker becomes a big problem for the developers, we could reconsider. But I doubt we would pick a closed source system like Github.
Did someone ask this person what the bug was? because we still don’t know
Likewise, I’ve filed a number of tickets with Haiku over the years and I’m not interested in signing up for GitHub. The probable upshot of a move to GitHub is its ceasing to receive feedback from Emacs development, make of this what you will.
I fail to see how those two facts are connected. For every software there’s always less developers than users (otherwise it’d be quite sad for its developers), but that doesn’t have to mean the users should deal with non-user friendly interfaces to report a bug. And to make it more user-friendly we don’t even need to switch to another bugtracking system. OAuth 2.0 login would solve pain points with registration by allowing users to login with their GitHub/GitLab/Google/Apple/etc account.
This sentence deserves to be put on Trac as a banner for non-registered users, probably with some predefined bug report template.
There is a single-sign-on system but right now it is in use only for Gerrit (and thus, not “single” sign-on at all, you need different accounts for Trac and the forums). Some work is needed to update the Oauth 2.0 plugin for Trac to make it work with it, I think.
No, but there is a lot of work after a bug is reported, and if we picked Github, this side of things is largely ignored by it. Yes, you can easily write a bug report in 3 clicks, very cool. But for a project with thousands of bug reports, the work of developer and people triaging bugs will not be easy at all. So, in the end, you get a lot of bugreports that essentially end up in a black hole with no one looking at them ever again.
If we were to consider a change of tool, we should consider this, and not just “how easy it is for users to report bugs”. Trac has, so far, done a very good job at managing 15+ years worth of tickets. There are other tools that may compete with it on this aspect, but Github isn’t one of them.
As I wrote, we don’t need to switch to GitHub (or smth else) to make the bug reporting UX better. SSO once done will remove the entrance barrier for the users who see Trac for the first time in their lives. Another thing could be a few UI adjustments like increasing the font sizes I was posting about some time ago (back then there was an intention to change it, but people couldn’t find where is the haiku.css file stored). Other than that, I find the Create New Ticket page quite usable and straightforward to work with, there’re not too many fields to fill-in, you can attach files and pictures, and it has a live preview. What else does one need?
That solution would be more intended for people who, once in their life time, will test Haiku and go to something else. Why people who don’t want to create a Trac account, would create a forum account?
On the forum, posts are buried in a very short time. If none answers, it takes only two or three days. That’s why the bug tracker is the way to go. It’s not a question of making the police, it is just the logical thing to do. Perhaps, sometimes, it should be asked with more delicacy.
The problem is that often beginners don’t know what they need to provide to get their bug fixed. How many times we are seeing posts saying “This doesn’t work” without further explanations? Experimented users on the forum are glad to help gathering intel to fill a proper ticket and even to open tickets on behalf of other users. But, it is still better when people encountering the bug open the ticket themselves because they will receive the notifications when a dev is looking at it, requesting more intel, asking to test a solution or closing the ticket. If someone opened the ticket on your behalf, he surely can’t do these things. And without these interactions it is often not possible to fix the bug. It will probably end up closed after ten years because none gave more intel, in the hope that somehow an update did the trick.
There is even a technical reason why we don’t use GitHub (or Gitlab, for that matter): we were using SVN before git, and it had those nice revisions where you could have a feeling about how old a commit is, just by looking at its number. That’s why we use tags intensively to bring this number to git.
It turns out that those tools could not handle that many tags when we considered our options.
A lot of food for thoughts, thanks for taking the time to explain your points of view.
For the benefit of making everyone aware of it, there are some knowledge that I can share regarding the pains that were raised:
Github doesn’t require the WebUI to be used, in fact I mostly use the command line. “gh” command takes care of everything you can do with the UI: https://cli.github.com/
Compnents, Issue Type etc… Can be done with GitHub, the Apache Arrow repository makes extensive use of them: Issues · apache/arrow · GitHub and it’s as easy as clicking on one to filter for that component (for example only see Parquet related issues: Issues · apache/arrow · GitHub )
Git is fairly able to handle huge numbers of tags, releases and branches. For example the Crossbow repository (runs nightlies for Arrow) does a release+tag for each nightly run. There are currently 120.000 releases → Releases · ursacomputing/crossbow · GitHub Haiku has a total of 65k commits, so even if every commit was a tag it would still be less than crossbow
Issue reporting experience on GitHub is fairly customizable, for example it’s possible to ask questions to the user and fill a template for issue reporting. Using Arrow again as an example, it asks the kind of issues as soon as an issue is open: New Issue and when you open a bug the form asks for what component you are reporting it: Bug Report. When a new PullRequest is opened, the automation will frequently tag it with the right component based on which source files were modified and will suggest reviews from the people contributing the most to those source files. So a lot of the GH experience can be customized.
Regardless, I think many new comers will start to expect that they can use the same tool they use for all other OSS projects when contributing to Haiku so over time I fear that a move to something more widespread (and not designed in the '90s) than Trac will become a necessity. Projects like SerenityOS also took traction because it was easy to contribute to them
I am not a developer … but I think they can use the same “tool”
as for other OSS projects … which is
… git.
Versioning system is the most common among projects nowadays
I wouldn’t determine Github as a ‘tool’ , but rather
→ as a developer : a kind of freely available, low cost infrastructure – with cons and pros for any specific projects - based on their needs/requirements. This way it won’t fit for all people/teams which are develop softwarers right now. Otherwise alternatives also would not be coexist.
I think devs can pick of it what they would use of this infrastructure :
source repository
store documentation
follow versioning history
changes, patch management
ticketing
donation
etc.
→ as an end user - primarily a website with open source projects
I can search / read about purpose/goal of these projects,
and some cases I can get some files from there to update application features/fix in between the releases
( like the frequently modified youtube.luac file of VLC)
and if I decide so, in case Haiku project :
register an account to be able
to make a more recommended way of donation by the project itself
open an Issue for 3rd party - ported - apps of Haikuports
Why would such people take the time to report bugs, and why should we spend time fixing these bugs if it was their once in a lifetime test of Haiku?
A tool written in Go, which doesn’t run on Haiku.
There is a single level of tags. Haiku tickets have a hierarchical component system, in addition to issue types (bugs, enhancements, tasks), a distinction between versions and milestones, and we can further customize this if needed. I use Github a lot (for personal projects, whichI am migrating out of it progressively, and also for my paid job), when I say it has limitations that would make it not work for Haiku, it’s not by ignorance.
When we tried this with github, we broke their ui. The releases/tag page wouldn’t render at all. That explains, as Axel said, why we picked a different option at the time (to host our own git server). That particular hroblem has been solved since, but it was not the only reason for this decision: there is the fact that Github is closed source, that our past reliance on a third party did not go well (some people may remember the Berlios svn server we used frequently being unusable on weekends because its hard disk was full, there were very different times). The switch was also made around the time when sourceforge started distributing adware, and google code hroject hosting was shutting down.
Not all of this is applicable today, of course.
The main issue remains: using a closed source tool is out of the question. If you want Haiku to consider Github, you first have to convince Microsoft that they should release Github sourcecode under an open source license. And then implement all the things needed to make it work like trac, make it not randomly use 100% CPU in WebPositive, and so on.
Meanwhile, Trac has been working great for us and many other projects, and was there first. Sure, it needs a bit more configuration and setup, but it is an excellent tool for tracking bugs. There is no reason to change a tool that works perfectly for us, and especially not fora closed source alternative.
I wouldn’t define Trac as a “excellent tool”. It’s an okish tool for people that deal with it daily, but that’s mostly just because you get used to its terrible UI and UX. I used it for years and honestly it has always looked pretty unreadable and a confusing wall of text to me. With a lack of convenient interaction patterns and autocompletion utilities that are nowadays pretty standard. When I had opened my first bug on Haiku I remember thinking “Oh, no, not Trac again”.
I understand your point of view, but I encourage you to consider if “works for me so it must work for everyone” is a wise long term strategy for the contribution experience of an OSS project.
PulkoMandy didn’t say that everyone should use it. Not sure where you read that.
Something like subcomponents and beeing able to querry bugs like this is quite important for our workflow, and yes that requires that bugs be entered into trac… But we don’t require or expect users to know all the right components, version, tags etc. You can leave all those empty and we (that is, us developers) will triage the bugs, set the component, version field etc.
Perhaps we could even disable some field in the bug entry mask for new users (like the tag field)
I’ve used github issues in the past and had trouble finding even tickets I filed myself, github is also to querry based on some things too, but instead of having easy drop downs for all the right things… it has a text field and you are supposed to just know the text syntax, that is a major UI regression to me, not an improvement.
What things in trac do you expect to be autocompleted? (and in what way?)
(I’d think stuff like components beeing a fixed list is a form of autocompletion, I’m confused what you want more than that, fields that are likely known like the version are also preset)
This sentence deserves to be put on Trac as a banner for non-registered users, probably with some predefined bug report template.