5 ms·

I can't stop laughing at the idea of GitLab struggling to render 100k lines of changes. Please actually attempt the ideas you are suggesting before suggesting

I can't stop laughing at the idea of GitLab struggling to render 100k lines of changes. Please actually attempt the ideas you are suggesting before suggesting them. This set of changes (and other large ones like it) is partially why the kernel needs to use email instead of <insert bloated Ruby application here>.

charcircuit 5y ago
I'm sure it could handle you viewing each commit one at a time just how with email you would look at each commit one at a time.
xyzzy_plugh 5y ago
> why the kernel needs to use email instead of This sort of implies that the Kernel would use something centralized if it worked well, which I don't believe to be true. Using email is very much an intentional choice and a desirable solution.
- CameronNemo 5y ago
  Yeah which is why I put the word "partially" in front of that out of context quote.
- charcircuit 5y ago
  >This sort of implies that the Kernel would use something centralized if it worked well, which I don't believe to be true. The mailing list that they use now is centralized. It works by everyone sending a message to a single email address. The owner of that address then sends the email out to all of the subscrbers of the mailing list. Having everyone who wants to upstream their patch directly to the kernel submit their work to a single website is not much different than them sending it to a single email.
  - hnaccount_rng 5y ago
    But that isn't how it works right? You send your pull requests to the relevant maintainer, CC people that you think should be aware _and_ send it to the mailing list (probably also "only" via CC). This here for example is sent to Linus directly and that part does _not_ depend on the mailing list. The mailing list is just a convenience feature for people that _want_ to be aware but may be looked over/forgotten by the submitter (which still happens, and people regularly say stuff like "also CC'ing additional relevant people"). Yes you could, at least in principle, also do that via GitHub/GitLab/whatever. But a) you wouldn't gain anything (the kernel already has all the tooling it needs and it's large enough to just create missing tools, heck git was literally written for it), b) you would introduce a massive single point of failure that either i) is _not_ under control of the kernel.org team or ii) needs a massive amount of resources to host (see the fun people poke at displaying 2k commits in GitLab). Neither seems like a good use of the kernel development resources. And if you want to contribute to the kernel... using a mailing list is an absolutely trivial problem.
ncann 5y ago
It's not like you would render and display the diffs in 2k emails at the same time either.
- wtallis 5y ago
  Didn't git do exactly that in preparing those emails to be sent? I wonder how long it took for that command to run.
  - db48x 5y ago
    Probably very, very quickly. git-format-patch is very fast; all it has to do is diff the files involved in each commit, which is already heavily optimized. No syntax highlighting (your email program can do that if you want it), or line numbering (ditto).
    - bonzini 5y ago
      Don't discount the heaviness of rendering the HTML on the client, too!
    - db48x 5y ago
      61.65 seconds to create all 2,298 emails on my computer, with the repository on spinning rust. That’s about one fortieth of a second each on average.
- CameronNemo 5y ago
  The difference is in one case a centralized server is expending a lot of resources to show something to the user, and in the other case it all happens locally and has no effect on the kernel.org infrastructure.
  - encryptluks2 5y ago
    I don't think the issue is with the centralized server, but the browser and the JS components they use. I prefer local anyhow.
nyanpasu64 5y ago
GitLab is awful and slow at rendering large changes. Sometimes when folding and unfolding files, the scroll position will jump around (though I'm unsure if that's a browser extension). And when viewing standalone files, KDE's Invent GitLab server is slow and can take 5-10 seconds to render a few thousand lines and send it to the client as JSON with syntax highlighting, before the file contents show up.
- masklinn 5y ago
  > GitLab is awful and slow at rendering large changes So’s github, anything of a non-trivial size it just won’t show by default and you need to re-request every time. It starts struggling around the kloc scale, and the browser itself soon follows as the dom is not the neatest and you start getting tab memory above half a gig, which I assume also makes the JS start killing itself or something. Good times.
- merb 5y ago
  gitlab can't render this changeset. gitlab has a limit what it can render.

charcircuit 5y ago

I'm sure it could handle you viewing each commit one at a time just how with email you would look at each commit one at a time.

xyzzy_plugh 5y ago

> why the kernel needs to use email instead of This sort of implies that the Kernel would use something centralized if it worked well, which I don't believe to be true. Using email is very much an intentional choice and a desirable solution.

CameronNemo 5y ago
Yeah which is why I put the word "partially" in front of that out of context quote.
charcircuit 5y ago
>This sort of implies that the Kernel would use something centralized if it worked well, which I don't believe to be true. The mailing list that they use now is centralized. It works by everyone sending a message to a single email address. The owner of that address then sends the email out to all of the subscrbers of the mailing list. Having everyone who wants to upstream their patch directly to the kernel submit their work to a single website is not much different than them sending it to a single email.
- hnaccount_rng 5y ago
  But that isn't how it works right? You send your pull requests to the relevant maintainer, CC people that you think should be aware _and_ send it to the mailing list (probably also "only" via CC). This here for example is sent to Linus directly and that part does _not_ depend on the mailing list. The mailing list is just a convenience feature for people that _want_ to be aware but may be looked over/forgotten by the submitter (which still happens, and people regularly say stuff like "also CC'ing additional relevant people"). Yes you could, at least in principle, also do that via GitHub/GitLab/whatever. But a) you wouldn't gain anything (the kernel already has all the tooling it needs and it's large enough to just create missing tools, heck git was literally written for it), b) you would introduce a massive single point of failure that either i) is _not_ under control of the kernel.org team or ii) needs a massive amount of resources to host (see the fun people poke at displaying 2k commits in GitLab). Neither seems like a good use of the kernel development resources. And if you want to contribute to the kernel... using a mailing list is an absolutely trivial problem.

ncann 5y ago

It's not like you would render and display the diffs in 2k emails at the same time either.

wtallis 5y ago
Didn't git do exactly that in preparing those emails to be sent? I wonder how long it took for that command to run.
- db48x 5y ago
  Probably very, very quickly. git-format-patch is very fast; all it has to do is diff the files involved in each commit, which is already heavily optimized. No syntax highlighting (your email program can do that if you want it), or line numbering (ditto).
  - bonzini 5y ago
    Don't discount the heaviness of rendering the HTML on the client, too!
  - db48x 5y ago
    61.65 seconds to create all 2,298 emails on my computer, with the repository on spinning rust. That’s about one fortieth of a second each on average.
CameronNemo 5y ago
The difference is in one case a centralized server is expending a lot of resources to show something to the user, and in the other case it all happens locally and has no effect on the kernel.org infrastructure.
- encryptluks2 5y ago
  I don't think the issue is with the centralized server, but the browser and the JS components they use. I prefer local anyhow.

nyanpasu64 5y ago

GitLab is awful and slow at rendering large changes. Sometimes when folding and unfolding files, the scroll position will jump around (though I'm unsure if that's a browser extension). And when viewing standalone files, KDE's Invent GitLab server is slow and can take 5-10 seconds to render a few thousand lines and send it to the client as JSON with syntax highlighting, before the file contents show up.

masklinn 5y ago
> GitLab is awful and slow at rendering large changes So’s github, anything of a non-trivial size it just won’t show by default and you need to re-request every time. It starts struggling around the kloc scale, and the browser itself soon follows as the dom is not the neatest and you start getting tab memory above half a gig, which I assume also makes the JS start killing itself or something. Good times.
merb 5y ago
gitlab can't render this changeset. gitlab has a limit what it can render.