To me it seems absurd that such organization like Mozilla uses third-party hosting like GitHub instead of something self-hosted or at least running under their own name. I understand that one-person projects use GitHub, but forcing contributors to make account with third-party service seems contributor-hostile.
Mozilla Firefox – Official GitHub repo
281–290 of 481 posts
Re: Mozilla Firefox – Official GitHub repo
#282Earlier quoted context omitted.
I find both Wikipedia and Git docs typically more useful than this. Much more. (They ain't perfect, of course.)
https://en.wikipedia.org/wiki/Declination "In astronomy, declination (abbreviated dec; symbol δ) is one of the two angles that locate a point on the celestial sphere in the equatorial coordinate system, the other being hour angle. The declination angle is measured north (positive) or south (negative) of the celestial equator, along the hour circle passing through the point in question." Anyone who doesn't know what d…
> Anyone who doesn't know what declination is, know from reading the introductory paragraph of this scientific Wikipedia article?
Why should this be a metric one would want Wikipedia to meet? It's an encyclopedia, not an astronomy course.
Of course, the brilliance of Wikipedia is that if you think you can write a clearer intro, you can do so! You could even add it to the simple language version of the page - https://simple.wikipedia.org/wiki/Declination
Re: Mozilla Firefox – Official GitHub repo
#283I hope the bugzilla stay there even if only read only. There is a lot of historical data in there, especially for the web which was built as a "ad-hoc" platform, many times when you wonder why does X the answer can only be found in bugzilla (which will explain that some random website that used to be major but doesn't even exists anymore, did something for some browser that used to be major but doesn't even exists anymore).
Re: Mozilla Firefox – Official GitHub repo
#284Pretty cool that Linus Torvalds invented a completely distributed version control system and 20 years later we all use it to store our code in a single place.
The code is still distributed. Every git clone usually creates a new, self-preserving copy (if we ignore some special flags). The problem is those features, which GitHub is offering outside of code. And I guess the irony is that GitHubs success is probably the reason nobody is adding them to git itself. Like add some subfolders into the repo for issues, wiki, discussions, etc. and have a UI for handling them all, easy. Instead, we have forges&tools supporting separate repos with flavours of widely used formats, making everything more complicated...
Re: Mozilla Firefox – Official GitHub repo
#285Pretty cool that Linus Torvalds invented a completely distributed version control system and 20 years later we all use it to store our code in a single place.
People have forgotten just how bad centralised version control was in 2005. If you weren't connected to the internet, you couldn't do a thing. You couldn't checkout. You couldn't commit. You could create branches. The only thing on your computer was whatever you checked out last time you were connected to the server. People talk about SVN, but it wasn't that common in 2005. None of the project hosting platforms (like…
I am sure Sourceforge supported subversion by 2007 or 2008, I had a project there then. When was it added?
Re: Mozilla Firefox – Official GitHub repo
#286(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…
I suspect that Firefox is not bottlenecked on number of bug reports they got.
Re: Mozilla Firefox – Official GitHub repo
#287I think it's actually an understandable strategical move from Mozilla. They might loose some income from Google and probably have to cut the staff. But to keep the development of Firefox running they want to involve more people from the community and GitHub is the tool that brings most visibility on the market right now and is known by many developers. So the hurdle getting involved is much lower. I think you can dis…
I absolutely gave up on trying to contribute a patch to Firefox because the combination of both gh and phabricator was too much for me.
I struggled to understand how the two interacted with each other, and I didn't know how to 'update my branch/pr' and I eventually just gave up.
Re: Mozilla Firefox – Official GitHub repo
#288Earlier 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.
You just showed the poster-child of gatekeeping that is harming Open Source. Every contributor is valuable, it's in the name, the definition of "contribute". Any bar to entry is bad, it certainly never is the solution to a different problem (not being able to manage all contributions). If anything, in the longer run, it will only make it worse. Now, to be clear, while I do think GitHub is currently the "solution" to…
> Every contributor is valuable, it's in the name, the definition of "contribute".
No. I definitely seen people who created multitude of misleading bug reports, flood of stupid feature requests. I personally did a bit of both.
There are people who do both repetitively, fill issue reports without filling requested fields. Or open issue again when their previous report was closed.
I got once bug report where someone was ranting that app is breaking data. Turned out (after wasting my time on investigating it) that user broke data on their own with different software, through its misuse.
There were PRs adding backdoors. This is not a valuable contribution.
There were PRs done to foment useless harmful political mess.
Some people pretend to be multiple people and argue with themselves in pull requests or issues (using multiple accounts or in more bizarre cases using one). Or try to be listed multiple times as contributor.
Some people try to sneak in some intentionally harmful content one way or another.
Some contributors are NOT valuable. Some should be banned or educated (see https://www.chiark.greenend.org.uk/~sgtatham/bugs.html ).
Re: Mozilla Firefox – Official GitHub repo
#289Earlier quoted context omitted.
The annoying thing about Fossil is that it doesn't let you squash commits, not even in your private branches - they have some kind of philosophical point about that. If you happen to agree with it, then yeah, it's great. If you like to commit quick and dirty and then tidy it up by squashing into logically complete and self-consistent commits, too bad.
I can certainly see the appeal of having neat commits but I tend not to worry about them. On a couple of occasions, with my university writing, having a immutable history helped me figure out, for example, how something had ended up in a final draft without citation. I'd deleted the citation which was a quick URL paste in a comment block in an earlier draft, and I'd never saved it to zotero. If I'd been able to tidy…
The appeal depends on how messy your commits are to begin with. When you know that commit history can be rewritten later, it suddenly becomes okay to commit incomplete code that doesn't properly run or even build, effectively using git as an undo system with branching. But the resulting history is completely unsuitable for any future attempt to use `git blame` and such.
Re: Mozilla Firefox – Official GitHub repo
#290Earlier quoted context omitted.
That problem is solved by preventing forced pushes. Rewriting history locally is encouraged.
Prevent forced pushes on protected branches (develop, main, hotfix etc.). I don't care if somebody force pushes their private feature branch.
Force pushing onto PR branches is the only way to make the commit history in them sane.
But GH's PR process is broken anyways. I miss Gerritt.