291–300 of 481 posts
Earlier quoted context omitted.
Maybe if Mozilla gave one hundredth of their CEO's salary in donation to Codeberg they would be more than happy and able to scale to nine nine :p
Maybe. Maybe not. If I was the person responsible for the code, I wouldn’t want to gamble on them becoming good enough for me to use.
Earlier quoted context omitted.
This isn't a platform issue — it's a problem with the PR system, and arguably with open source itself. If you're unwilling to spend time on anything beyond writing code, maybe keep the project closed-source.
Or, more obviously, make it open-source, and make a big fat note in the README of "I will not accept PRs, this repo is just for your consumption, fork it if you want to change it".
Earlier quoted context omitted.
In my experience, most contributors who are deterred from contributing because they can't use GitHub aren't particularly valuable contributors. I'm sure there's exceptions, but I haven't seen any for non-trivial open source projects I've been involved in. I might even argue that it could be good to have a slightly higher bar to deter low quality one time contributors.
I can say that I've chosen not to bother when submitting a fix requires me to stray away from GitHub, and doubly so when it doesn't use a PR/MR workflow. There are only so many hours in the day, and I don't have the patience to deal with unconventional workflows when there are other things I could be doing with my time. For projects that I'd be interested in being a long-term contributor to, this is obviously differe…
"Friction in signing up" being a big part for you is also weird, considering basically all free software GitHub alternatives (Gitea, GitLab, Forgejo) support SSO via GitHub.
Earlier quoted context omitted.
> what exactly is being lost by moving the repository to GitHub? Alternatives to github We lament Google's browser engine monopoly, but putting the vast majority of open source projects on github is just the expected course to take. I guess we'll repeat history once microsoft decides to set in the enshittification, maybe one day mobile OSes replace Windows and they're strapped for cash, who knows, but it's a centrali…
Did you ever use the alternatives before GitHub took off? GitLab? It was awful. Slow, and paying for that kind of experience felt like a bad joke. It's much better now but it was borderline unusable back in the day. Or SourceForge, before Git was mainstream? Also terrible. GitHub succeeded because it quickly established itself as a decent way to host Git - not because it was exceptional, but because the competition h…
not really
just moving issue tracker and discussions is highly annoying
trying to get your users to move is likely hard and you will lose many
still, may be easy in comparison
Earlier quoted context omitted.
If you don't rewrite history in git, I don't want to bisect in your repos. If you push rewritten history to master, you're a git. Conclusion: learn your tools.
The modern workflow is just to let GitHub squeeze yor shit commits into one and then rebasing that.
It's not my favourite process, but...
(I work at Mozilla, but not on the VCS tooling, or this transition) To give a bit of additional context here, since the link doesn't have any: The Firefox code has indeed recently moved from having its canonical home on mercurial at hg.mozilla.org to GitHub. This only affects the code; bugzilla is still being used for issue tracking, phabricator for code review and landing, and our taskcluster system for CI. In the s…
> This only affects the code; bugzilla is still being used for issue tracking Grim. The best reason to be using github at all is to maximize the portion of your users who are comfortable submitting bug reports, as they already have an account and are familiar with how the platform works (due to network effects.) Projects which host code on github but chose not to take bug reports there are effectively gate keeping bu…
That said, there are also other teams and projects who do use GitHub for issue tracking. However the closer to Firefox/Gecko you are the harder this gets. For example it's hard to cross-reference GitHub issues with Bugzilla issues, or vice versa. I've seen people try to build two-way sync between GitHub and Bugzilla, but there are quite considerable technical challenges in trying to make that kind of cross-system replication work well.
However your point that GitHub makes issue submission easier for people who aren't deeply embedded in the project is a good one. I'm directly involved with webcompat.com, which aims to collect reports of broken sites from end users. It's using a GitHub issue tracker as the backend; allowing developers to directly report through GitHub, and a web-form frontend so that people without even a GitHub account can still submit reports (as you can imagine quite some effort is required here to ensure that it's not overwhelmed by spam). So finding ways to enable users to report issues is something we care about.
However, even in the webcompat.com case where collecting issues from people outside the project is the most important concern, we've taken to moving confirmed reports into bugzilla, so that they can be cross-referenced with the corresponding platform bugs, more easily used as inputs to prioritization, etc. That single source of truth for all bugs turns out to be very useful for process reasons as well as technical ones.
So — (again) without being any kind of decision maker here — I think it's very unlikely that Firefox will move entirely to GitHub issues in the foreseeable future; it's just too challenging given the history and requirements. Having some kind of one-way sync from GitHub to Bugzilla seems like a more tractable approach from an engineering point of view, but even there it's likely that there are non-trivial costs and tradeoffs involved.
Earlier quoted context omitted.
I get what you're saying, but tbf hosting on github doesn't (yet!) box you out of just moving back to that system. It's still just git. It's still distributed, in the sense that if github goes down you could still generate patches and email them around, and then push back to github when it's back. Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by dist…
>> I would love a good issue tracking system that is done entirely inside git You might like git-bug: https://github.com/git-bug/git-bug
This should be one of the very first links in the readme.
(I work at Mozilla, but not on the VCS tooling, or this transition) To give a bit of additional context here, since the link doesn't have any: The Firefox code has indeed recently moved from having its canonical home on mercurial at hg.mozilla.org to GitHub. This only affects the code; bugzilla is still being used for issue tracking, phabricator for code review and landing, and our taskcluster system for CI. In the s…
Earlier quoted context omitted.
I would say that using GitHub only for a public git repository is pretty good value. It is free and robust, and there is not much bad Microsoft can do to you. Because it is standard git, there is no lockdown. If they make a decision you don't like, migrating is just a git clone. As for the "training copilot" part, it is public, it doesn't change anything that Microsoft hosts the project on their own servers, they can…
I am banned from GitHub because I didn't want to give them my phone number. They ignored a legally binding GDPR request to delete all my data. I haven't got around to suing them yet. Recently I also got "rate limited" after opening about three web pages. Microsoft can do something to you, and that is to arbitrarily deny you access after you've built a dependence on it, and then make you jump through hoops to get acce…
However, it is clearly not correct to say that you were banned from GitHub. It’s like saying “I was banned from Google because I refuse to use computing devices.”
Not really a ban, just self flagellation, which, again, whatever works for you.
Earlier quoted context omitted.
I think it can be done half/half. Do some, well-defined builds at GitHub and pull in for testing. Another comment tells that some users needed 10+ minutes to get a lock to pass their tests through CI, so maybe some sanity tests can be offloaded to GitHub actions. I'm not claiming that my comment was 100% accurate, but they plan to move some of the CI to GitHub, at least.
> but they plan to move some of the CI to GitHub, at least Really? I've seen no indication of that anywhere, and I'd be amazed if they did. They're not using github PRs, and github actions really fights against other development workflows... not to mention they already have invested a lot in TaskCluster, and specialized it to their needs. Where are you getting that from?