191–200 of 251 posts
Earlier quoted context omitted.
You are pulling the commits from another repository. The base repository is behind the forked repository and the forker is asking the base to incorporate (pull) the changes (commits).
Why does it need to focus on who is doing it? I think merge is generic enough term that can describe both actors (i.e. if you for example have a right to write into upstream, you can merge it yourself, without asking the primary owner.
As I understand, Daniel Vetter is proposing a "monotree" as a source code control pattern where a monorepo (and its branches) is not the primary place where development is done, but is rather where works are integrated from subordinate repositories. In particular, he's asking for GitHub to support coordination (issues and pull requests) spanning upstream repositories that are indicated by a particular change request.…
Especially in a world where GVFS is a thing (not quite yet), I fail to see the advantage of a monotree over a monorepo with lots of branches and scripting around a MAINTAINERS file. What's wrong with branches and folders? Why are upstream repositories needed? (My hunch is the answer is just "it's slow with that much code" to which I again say "not when GVFS is ready"). Not to say Linux should change their ways, just…
Not sure about the Linux kernel (no enough experience) but same issue across multiple projects looks something necessary...
Earlier quoted context omitted.
Especially in a world where GVFS is a thing (not quite yet), I fail to see the advantage of a monotree over a monorepo with lots of branches and scripting around a MAINTAINERS file. What's wrong with branches and folders? Why are upstream repositories needed? (My hunch is the answer is just "it's slow with that much code" to which I again say "not when GVFS is ready"). Not to say Linux should change their ways, just…
GVFS has been working for years, but it's not even used related to the linux kernel at all. It's actually a GNOME-thing.
As I understand, Daniel Vetter is proposing a "monotree" as a source code control pattern where a monorepo (and its branches) is not the primary place where development is done, but is rather where works are integrated from subordinate repositories. In particular, he's asking for GitHub to support coordination (issues and pull requests) spanning upstream repositories that are indicated by a particular change request.…
Especially in a world where GVFS is a thing (not quite yet), I fail to see the advantage of a monotree over a monorepo with lots of branches and scripting around a MAINTAINERS file. What's wrong with branches and folders? Why are upstream repositories needed? (My hunch is the answer is just "it's slow with that much code" to which I again say "not when GVFS is ready"). Not to say Linux should change their ways, just…
But then I realized that the advantage of multiple repos is that it is decentralized: anyone can start their own fork, and collaboration works similar to the official forks, and you don’t need any centralized administration.
Having everyone share a single giant monorepo sounds like you’ll need a lot of people to support the infrastructure. Microsoft can do that. Can the Linux community?
With a huge monorepo, you can easily archive everyones contributions. That’s probably important for Microsoft. It’s not important for Linus — he only cares about the stuff he merges.
Finally, multiple repos allow people to work on stuff privately, and only contribute back to the public when they are ready.
I can't really see the obsession that everyone has with centralised and closed services like github. We need to start moving away from them, not move more projects to them. Mailing lists and NNTP make decentralisation quite easy while being open standards and without having the need to have any account in any centralised service, why drop all these features away?
> We need to start moving away from them, not move more projects to them. It seems this topic comes up quite frequently on HN. Unfortunately, while it sounds great in theory, no one ever has a practical way of doing this. The main problem here is the user experience. When using GitHub I can find an open source project, copy the URL, pull it down, make changes, push and click a button for a pull request. A little bit…
Earlier quoted context omitted.
Dude, you have no idea what you're talking about and you're wildly speculating. And it's pretty offensive, to be honest. I'm not "seething", this isn't even close to the defining moment of my career, and I'm not on a crusade. You're trying to portray me as some crazy caricature because it allows you to ignore my argument. That's not even remotely okay. My argument has nothing at all to do with that one interaction, a…
>Please don't reply to me again. That about sums it up. Nothing more to say, it is its own caricature.
Earlier quoted context omitted.
Kernel development shouldn't have a low bar, it should have a very very high one. Anyone that finds email a high bar for communication doesn't belong in Kernel development.
This is gate keeping at its finest. Email is a clunky tool to do development with compared with what is available. A persons willingness to use email (and all the quirks for submitting a patch) for patching the kernel has nothing to do with the quality of code that they write.
If you won't submit a kernel patch because you feel that email is unfashionable, then you're kind that should be kept out of the gate. Sorry.
I actually really like the MAINTAINERS file. Keeps the metadata literally in the repository and doesn't rely on an external system.
Yes, this is similar to how I would like to handle issues: just an issues directory full of yaml-markdown files. That way, issues are a part of the same history as the code. They can be specific to a branch, they can diverge as different solutions are attempted in parallel, and they can be deleted and retrieved after resolution.
Earlier quoted context omitted.
There are two major mobile operating systems, iOS and Android, both based on Unix clones, one on BSD and one on Linux. Mobile has dramatically increased Linux usage; what do you think Android is?
You bring up valid points. However, ios makes most of the mobile profit just as windows and Mac do over Linux for desktop (I have only used Linux in server industry so I don't know how they fair in those markets too much). In that light, How about this prediction. Linux will continue to dominate in the server market for a long time as businesses factor in the cost of os licenses and the supply of linux users is big.…