Does anyone have one of these that could confirm if that’s realistic? I’ve seen many laptops with similar specs and claims that come out to significantly lower battery life unless you do nothing but stare at an empty desktop.
Wine is much, much better at this point. In particular, Darling doesn’t have much support for GUIs yet, so unless it is a command line tool you probably want to stick with Wine.
I agree, and GitHub allows choosing how to merge each PR individually if you need to do something different for a specific PR. Large PRs like that are at most 1% of our total PRs, and we review those more per-commit and use a merge commit instead of a squash. By default we optimize for the other 99%.
I think the idea here is that reviewing individual commits is irrelevant if the plan is just to squash it all down. Each PR corresponds to a single change on the main branch in the end, the fact there was a main commit followed by a half size “fixed typos” and “fixed bug” commits doesn’t actually matter since it will be blown away in the end. The process results in the same clean history with good individual commits on the main branch, just as if the user squashes those commits locally before pushing it up to the code review platform.
Well squash and merge isn’t default or pushed in any way. It’s an option, and we chose to enable it ourselves because that’s what works best for us. It’s what works well for many other projects too, which is why many choose to enable it instead of the default merge commit.
GitHub has an option when merging a PR to “squash and merge”. This option squashes all of the commits on the PR branch into a single commit and cherry-picks it on top of the base branch. We use this by default in our open source projects at work. Most people are not gonna go through the effort of making a well defined patch series the way it would be required for a Linux kernel contribution. Most changes aren’t that big though and so it doesn’t really matter. Send as many commits as you want in the PR, I’ll just review the diff as a whole and squash it when I’m done. Workflows should adapt to user preference, not the other way, and this is a good example of that.
It’s rather bold of many of the commenters in this thread to assume they know the needs of Mozilla and their developers rather than those people themselves. GitHub makes complete sense, even if it doesn’t live up to some people’s desires for free software purity.
It’s the most widely used platform that the most people are familiar with that they get to use likely for free. Newer projects of theirs are also hosted there. Why would you say it makes no sense?
That’s not even what 12ft.io was. It wasn’t scraping anything, it was just a redirect to the google web cache. Importantly, it was also accessible, something that anyone could use without installing anything.
The phoronix forums are insanely toxic. Everything is bad. Gnome = kid’s toy. systemd = written by Satan himself. Every programming language = too slow. Anything vaguely interested in fostering a diversity, equity, and inclusion = true colors come out in full force.
It’s so toxic yet I subject myself to it every now and again. There’s absolutely no moderation going on and it shows.