this post was submitted on 06 Nov 2023
287 points (98.6% liked)

Linux

48077 readers
779 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

For a long time Firefox Desktop development has supported both Mercurial and Git users. This dual SCM requirement places a significant burden on teams which are already stretched thin in parts. We have made the decision to move Firefox development to Git.

  • We will continue to use Bugzilla, moz-phab, Phabricator, and Lando
  • Although we'll be hosting the repository on GitHub, our contribution workflow will remain unchanged and we will not be accepting Pull Requests at this time
  • We're still working through the planning stages, but we're expecting at least six months before the migration begins

APPROACH

In order to deliver gains into the hands of our engineers as early as possible, the work will be split into two components: developer-facing first, followed by piecemeal migration of backend infrastructure.

Phase One - Developer Facing

We'll switch the primary repository from Mercurial to Git, at the same time removing support for Mercurial on developers' workstations. At this point you'll need to use Git locally, and will continue to use moz-phab to submit patches for review.

All changes will land on the Git repository, which will be unidirectionally synchronised into our existing Mercurial infrastructure.

Phase Two - Infrastructure

Respective teams will work on migrating infrastructure that sits atop Mercurial to Git. This will happen in an incremental manner rather than all at once.

By the end of this phase we will have completely removed support of Mercurial from our infrastructure.

you are viewing a single comment's thread
view the rest of the comments
[–] Lord_ToRA@lemmy.world 18 points 1 year ago (2 children)

I agree that PRs are problematic, but that doesn't make GitHub "trash".

Also, that dude is so obnoxious and really seems to like to make broad generalizations of his opinion like it's fact.

[–] Scorpion3869@lemmy.ml 7 points 1 year ago* (last edited 1 year ago) (1 children)

and really seems to like to make broad generalizations of his opinion like it's fact.

None of what Brodie said is baseless, even if some are more opinion than fact. He sight's sources for a reason.

[–] Lord_ToRA@lemmy.world 4 points 1 year ago (2 children)

He sight's sources for a reason.

I'd hope so. It wouldn't be good if they were blind.

Anyway, I didn't question the accuracy of what he said, just that his manner of delivery is obnoxious and portrays an attitude of self-importance. It feels like he's yelling at the viewer with hostility.

Aussies tend to be quite direct. It's basically our natural state. I get how it can be perceived as hostile, but I don't actually think Brodie is very abrasive. He seems like a pretty relaxed guy.

[–] Scorpion3869@lemmy.ml 4 points 1 year ago (1 children)

He's literally talking to the viewer the same way the vast majority of YouTubers speak, he's just Australian.

[–] Lord_ToRA@lemmy.world 0 points 1 year ago* (last edited 1 year ago) (1 children)

the same way the vast majority of YouTubers speak

"Everyone else is doing it" is not a free pass. Absolutely none of the creators I watch speak like that, and I can list quite a lot. It's obnoxious.

[–] Scorpion3869@lemmy.ml 3 points 1 year ago* (last edited 1 year ago) (1 children)
  1. The video is 2y old.
  2. He's Australian.

Cut the man some slack.

[–] Lord_ToRA@lemmy.world -2 points 1 year ago (1 children)

Why do either of those matter towards being obnoxious?

Are all Australians obligated to be like that? Two years ago people were supposed to make videos acting obnoxious?

[–] Scorpion3869@lemmy.ml 3 points 1 year ago (1 children)

Right now, I'd say you're the one choosing to be obnoxious.

[–] Lord_ToRA@lemmy.world -2 points 1 year ago (1 children)

Because I'm answering you with logic?

[–] Scorpion3869@lemmy.ml 3 points 1 year ago* (last edited 1 year ago) (1 children)

Because you're being obnoxious.
Caring this much about how some YouTuber speaks is literally obnoxious and portrays an attitude of self-importance.

[–] Lord_ToRA@lemmy.world -2 points 1 year ago (1 children)

You've clearly just devolved into ad hominem attacks. Does your ego really hang on whether or not your YouTuber friend is perceived the way you want?

I just pointed out that the dude is obnoxious and you're over there trying to defend him with complete nonsense.

Move on, buddy.

[–] Scorpion3869@lemmy.ml 3 points 1 year ago* (last edited 1 year ago)

Move on, buddy.

🫴

[–] jaybone@lemmy.world 5 points 1 year ago (2 children)

I’m just curious, why are PRs worse on GitHub compared to other git hosting services?

[–] Rustmilian@lemmy.world 10 points 1 year ago* (last edited 1 year ago)

Instead of using valid commit messages they just slap on "#42" which isn't valid anywhere other than the GitHub web UI.

[–] IAm_A_Complete_Idiot@sh.itjust.works 3 points 1 year ago (1 children)

Also, GitHub PRs atleast to me feel like they encourage reviewing changes by the total diff of the entire PR, and not each commit. I don't want a slog of commits that don't add any value - it just makes doing things like reverts more annoying. Stuff like Gerrit and phabricator enforce reviews by making you review individual commits / changes / whatever you want to call them and not branch diffs.

[–] bamboo@lemm.ee 0 points 1 year ago (1 children)

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.

[–] IAm_A_Complete_Idiot@sh.itjust.works 3 points 1 year ago (1 children)

How much of that is what GitHub encourages and how much of that is what Users prefer? Plenty of users seem to enjoy phabricator / Gerrit for code review in practice precisely because of their workflows.

[–] bamboo@lemm.ee 1 points 1 year ago (1 children)

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.

[–] IAm_A_Complete_Idiot@sh.itjust.works 1 points 1 year ago* (last edited 1 year ago) (1 children)

Yeah, but phabricator and Gerrit are entirely separate workflows from GitHub, and a lot of people prefer that workflow because it leads to encouraging better histories and reviews. It helps you in getting rid of the "fixed typos" type of commits, while still letting you make larger PRs.

GitHub obviously does let you keep a clean git history, but the code review workflow in GH just doesn't encourage reviewing commits.

[–] bamboo@lemm.ee 1 points 1 year ago (1 children)

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.

[–] IAm_A_Complete_Idiot@sh.itjust.works 1 points 1 year ago* (last edited 1 year ago) (1 children)

Right, but squashed commits don't scale for large PRs. You could argue that large PRs should be avoided, but sometimes they make sense. And in the case where you do have a large PR, a commit by commit review makes a lot of sense to keep your history clean.

Large features that are relatively isolated from the rest of the codebase make perfect sense to do in a different branch before merging it in - you don't merge in half broken code. Squashing a large feature into one commit gets rid of any useful history that branch may have had.

[–] bamboo@lemm.ee 1 points 1 year ago

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%.