From: Eli Schwartz via Gdb <gdb@sourceware.org>
To: Mark Wielaard <mark@klomp.org>
Cc: "Tomasz Kłoczko" <kloczko.tomasz@gmail.com>,
"Sam James" <sam@gentoo.org>,
gdb@sourceware.org
Subject: Re: gdb and ancient GNU autotools
Date: Sun, 25 Feb 2024 16:19:28 -0500 [thread overview]
Message-ID: <5e663511-557e-43ee-9c96-6591041d8587@gmail.com> (raw)
In-Reply-To: <20240225104057.GC8121@gnu.wildebeest.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 2257 bytes --]
On 2/25/24 5:40 AM, Mark Wielaard wrote:
> Please don't be sarcastic. We do the exact same thing with our CI at
> https://builder.sourceware.org/ which gets new commits all the time
> sometimes fetching code for 20 builders at a time in parallel from
> different machines. So it is known to work. We aren't DDoSing
> ourselves. So we just have to figure out why it doesn't seem to work
> for Tomasz.
I think it's not entirely unreasonable for a project to internally place
its own demands on its own resources, with the knowledge of how much it
has in the way of resources...
especially when, per the buildbot logs, you are using persistent git
clones and fetching new changes on every buildbot run.
This is rather different from someone saying that he is building all
your projects on every commit when you didn't ask for that to be done,
and is NOT using git, and as a result of not using git, is getting
throttled by mysterious intricacies of gitweb vs cgit.
In fact, if I'm reading Tomasz correctly, in order to do this as an rpm
specfile build, he has automation hooked up to scan for every commit
landing on the binutils repo, then appending that commit as a gitweb
downloaded patchfile to the `Patch:` section of the spec.
So for example for the binutils-gdb case, that currently stands at 1626
separate gitweb downloaded patch files, and as soon as an email
notification comes in that the gdb repo has gotten a 1627th commit since
the latest tag, all those 1626 gitweb formatted patch files are going to
be downloaded again from scratch, except it is 1627 now.
This is why caching is not just:
> But yes, having a cache certainly helps.
Rather, it is "having a cache is basic politeness unto others".
It doesn't matter whether it works, and it doesn't matter whether
avoiding gitweb specifically and using cgit can make it better. It is
simply rude to do this altogether. Use a cache, or use git clones, or
best of all, use both -- just like builder.sourceware.org does.
Refusing to use a cache is called executing a DDoS campaign.
I am not being sarcastic.... okay, the "clapping" thing was a bit
sarcastic. But the DDoS Linux bit was meant in absolute seriousness.
--
Eli Schwartz
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 18399 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-02-25 21:20 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-24 16:28 Tomasz Kłoczko via Gdb
2024-02-24 16:51 ` Sam James via Gdb
2024-02-24 17:15 ` Tomasz Kłoczko via Gdb
2024-02-24 17:21 ` Sam James via Gdb
2024-02-24 18:30 ` Tomasz Kłoczko via Gdb
2024-02-24 19:31 ` Mark Wielaard
2024-02-25 0:22 ` Tomasz Kłoczko via Gdb
2024-02-25 7:56 ` Mark Wielaard
2024-02-25 8:05 ` Eli Schwartz via Gdb
2024-02-25 10:40 ` Mark Wielaard
2024-02-25 21:19 ` Eli Schwartz via Gdb [this message]
2024-02-25 21:50 ` Tomasz Kłoczko via Gdb
2024-02-25 22:20 ` Andreas Schwab
2024-02-25 23:32 ` Mark Wielaard
2024-02-26 0:29 ` Tomasz Kłoczko via Gdb
2024-02-26 0:46 ` Eli Schwartz via Gdb
2024-02-26 0:55 ` Tomasz Kłoczko via Gdb
2024-02-26 11:44 ` Mark Wielaard
2024-02-26 12:13 ` Tomasz Kłoczko via Gdb
2024-02-26 0:26 ` Eli Schwartz via Gdb
2024-02-27 15:25 ` Tom Tromey
2024-02-27 16:37 ` Simon Marchi via Gdb
2024-02-27 17:33 ` Joseph Myers via Gdb
2024-02-27 17:42 ` Tom Tromey
2024-02-27 20:44 ` Tomasz Kłoczko via Gdb
2024-02-27 20:57 ` Tomasz Kłoczko via Gdb
2024-02-27 20:59 ` Sam James via Gdb
2024-02-26 0:58 ` Andrew Pinski via Gdb
2024-02-27 15:27 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5e663511-557e-43ee-9c96-6591041d8587@gmail.com \
--to=gdb@sourceware.org \
--cc=eschwartz93@gmail.com \
--cc=kloczko.tomasz@gmail.com \
--cc=mark@klomp.org \
--cc=sam@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox