On Wed, 27 Aug 2025 at 15:49, Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> wrote: > > I have recommended that Link: trailers indicating the provenance of the series > should use a dedicated domain name: patch.msgid.link. This should clearly > indicate to you that following this link will take you to the original > submission, not to any other discussion. That doesn't fix anything. It only reinforces the basic stupidity of marking the WRONG DIRECTION. The fact is, YOU CANNOT SANELY MARK THE COMMIT. Dammit, why do people ignore this *fundamental* issue? You literally cannot add information to the commit that doesn't exist yet, and the threads that refer to bugs etc quite fundamentally WILL NOT EXIST YET when the commit is posted. The actual *useful* information about a commit is the discussions it resulted in, not the posting of the patch. And those will almost invariably be unrelated to the patch submission, since they either talked about the problems that the patch *fixed*, or talk about the problems that the patch *caused* (ie the thread starts with some random "My machine no longer boots", and then goes on from there as people try to figure out what caused it. So the *relevant* links are pretty much by definition not the link to the posting of the patch. Is it really so hard to understand and accept this fundamental issue? It's the *message* that should be indexed and marked, not the commit. What you want to find is messages on the mailing list that mention the commit, not the other way around. The other way around is completely pointless and CANNOT BE AUTOMATED. Any automation by definition will only add noise, not "information". Really. The only valid link is a link to *pre-existing* discussion, not to some stupid "this is where I posted this patch", which is entirely and utterly immaterial. And dammit, lore could do this. Here's one suggested model that at least gets the direction of indexing right (I'm not claiming it's the only model, or the best model, but it sure as hell beats getting the fundamentals completely wrong): (a) messages with patches can be indexed by the patch-id of said patch This might well be useful in its own right ("search for this patch"), and would be good for the series where the same patch ends up being re-posted because the whole series was re-posted. IOW, just that trivial thing would already allow the lore web interface to link to "this patch has been posted before", which is useful information on its own, totally aside from any future archeology. But it's not the end goal, it's only a small step to *get* to the end goal: (b) messages that mention a commit ID (or a subject line) could then have referrals to the patch-id of said commit. No, you don't want to do a whole-text search every time you look for a commit. That's fine for manual stuff, but it's much too expensive for any sane automation. But you *can* (and lore already does) scan messages at message posting time, and find when people refer to a commit, and then index that message *once* by the patch ID of the commit. Now, this *is* fundamentally useful in a very different way: if you have somebody who bisected something and mentions a commit as a result, you'd now *find* that kind of message, and the history leading up to it. So when people read threads on lore about bugs being bisected, think how useful it would be if that thread would basically auto-populate with "this message refers to this patch". And the final step is (c) have some 'b4' infrastructure to look up emails pertaining to a commit - by doing the patch ID and then looking up the indexing above Look, now you have a "open web browser with the history of not just where the patch was originally posted, but where that commit was *mentioned*". Notice how fundamentally more useful this is from some link to where the patch was posted? And absolutely nothing in the above implies tagging the commit with useless information. I look at the "Link:" tags quite regularly, and I can tell you that when it's a posting tag, it almost invariably is completely and totally useless. We *have* people who add those, and they only add noise and very little value. Do not add more of those useless garbage links in the name of "automation". It's not automating anything useful, it's only automating garbage. Because the *commit* already has all the information that is relevant - it's not the commit that is missing a link. It's the other side. Which is why those links to lore patch submission events are so STUPID. They add nothing. Doing them in the name of "automation" is crazy. It's entirely pointless. It's garbage and it's mis-designed, because it's not understanding the problem. Linus