Quotes of the week
Quotes of the week
Posted Feb 8, 2024 14:16 UTC (Thu) by error27 (subscriber, #8346)Parent article: Quotes of the week
I think the main problem with email is that a lot of people struggle to use git send-email, so now there is a web interface that automatically generates a patch thread. I haven't tried it, but I saw a thread from it recently so I know it exists.
Another tool that I would like is if lore could turn a thread into a pull request. This could be connected to b4 somehow. b4 pull_request <msg-id>. That would help to run CI testing. The kbuild-bot already does this for their testing, but I don't want to have to re-write the whole kbuild bot.
A second tool which would help would be if we could get the diff between two patch sets. So if it's a v4 patch, then it would look up the v3 patchset and show the diff with it. Someone could make a shell script that used b4 to do this.
I also wish that people used the Link: (or whatever) tag to link commits to the lore discussion. I asked the netdev people why they didn't and they said they would if that feature were integrated into patchwork.
Posted Feb 8, 2024 15:21 UTC (Thu)
by geert (subscriber, #98403)
[Link]
Like "b4 diff -v3 <msgid>"?
> I also wish that people used the Link: (or whatever) tag to link commits to the lore discussion. I asked the netdev people why they didn't and they said they would if that feature were integrated into patchwork.
As patchwork bundles do include the Message-Id headers, I am wondering what (if anything) needs to be changed in patchwork?
Posted Feb 8, 2024 21:06 UTC (Thu)
by mricon (subscriber, #59252)
[Link]
This exists already using:
b4 shazam -H <msgid>
Note, that this can fail if we can't figure out where in the history this patch/series belong (e.g. there is no base-commit information for the series).
> A second tool which would help would be if we could get the diff between two patch sets. So if it's a v4 patch, then it would look up the v3 patchset and show the diff with it. Someone could make a shell script that used b4 to do this.
This exists already using b4 diff, though it can also fail if we can't properly figure out where in the history things belong.
b4 docs are here: https://b4.docs.kernel.org/
Posted Feb 13, 2024 7:24 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (9 responses)
The main problem with email is that everyone wants LESS of it with the exception of Linux maintainers and their mutt macros. It's become a bit of a sect.
The main problem with mailing-lists is that they are "all or nothing". Either you're part of the club, or you're not. By default Github/Gitlab notify you only about threads you participated in or subscribed to. So you don't have an email filtering problem to solve in the first place because you're simply not receiving a gazillion of messages in the first place, which everyone very much likes. Worst case you have to click "unsubscribe" from some threads from time to time and that's it.
You can also ask Forges to send you a ton of email if you're a maintainer, they can do that too. It's just much more flexible.
And of course most of the discussion about one feature is in the same place, you almost never have to search and connect dots. Github's automatic "backlinks" are especially amazing: if a discussion ends up being split in more that one place, then mentioning issue B in issue A automatically creates links *both* ways.
There is a price to pay of course: you need a centralized database / single point of failure (the kernel has lore.kernel.org now but it's not a centralized SPOF, is it?), which probably relies partly on some closed-source software you have no control over. Some project managers may like that database and start to use it to track progress and people's work - the horror!
You may even have to use a... mouse and a web browser from time to time. Strangely enough, most people seem OK with that :-)
> The thing about mutt is that it's way faster than web interfaces and most kernel devs have macros set up to help them review patches faster.
It's way faster if your job requires to somehow "process" most of the firehose = you're a maintainer. For browsing and searching only the fraction that interests you in a large dataset, hypertext and a mouse are extremely efficient. Pointing and clicking is typically faster than the equivalent with a keyboard.
Also, there is this strangely persistent misconception that a database can only be accessed from a web browser. For sure it's the most common interface... nowadays. But of course not the only possible interface.
> Another tool that I would like ... A second tool which would help ...
Most of these problems have already been solved or do not even exist in the rest of the world. So the only persons who could "scratch their own itch" and implement these are the maintainers themselves who are too busy being very efficient processing thousands of emails. Or, the Linux Foundation has to pay people to do it.
This is really the most ironic/sad part of the story: the people who gave the world some of the most widely used open-source software on the planet (Linux, git, ...) can't re-use and collaborate with the rest of the world on code review tools because their email-based process is so unique and unusual. Sorry, I meant: because the whole world is wrong :-)
Meanwhile, Gitlab, sourcehut and others keep making progress. Very recently:
Posted Feb 13, 2024 11:39 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (8 responses)
At which point, you are now in an Echo Chamber, re-inforcing your likes and prejudices. Nothing wrong with that, but you're now *missing* an awful lot because you don't even realise it's out there ...
At the end of the day, the problem is "how do I cope with information overload". Neither mechanism is wrong, different mechanisms work for different people - hey I find using any mildly complex browser/mouse interface hell on earth. Give a pdf any day! And modern web browsers can't even generate a pdf, ffs!
What's needed is a system that treats ALL KINDS of people as first class citizens, and doesn't say to people "because you don't like text" or "because you don't like email" you're unwelcome.
Back in the day, if I hit a website with flash, it would get blocked instantly. Because, to me, it was UNREADABLE. Other people loved them.
Cheers,
Posted Feb 14, 2024 19:26 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (7 responses)
> At the end of the day, the problem is "how do I cope with information overload".
Yes and Github/lab and friends have a pretty good and extremely popular and successful solution to that problem. Meanwhile in deserted mailing-list land, people still assume a web browser is a required part of a database design. Now _that_ looks more like an "echo chamber".
Posted Feb 14, 2024 21:10 UTC (Wed)
by pizza (subscriber, #46)
[Link] (6 responses)
Er, no. My direct experience leads me to the opposite conclusion. $dayjob-1 used Github for some projects, and the volume of stuff I didn't care about (ie within my organization but not in the projects/etc I cared about) rapidly made github's notification system _completely_ unusable for anything. Literally hundreds of notifications a day.
....At least with email I can set up my own filters and read (or not) them on my own terms.
Ladders are great for climbing onto the roof of a small building, but they don't scale to even moderate-sized ones. Meanwhile, elevators are usually _slower_ than stairs for small buildings, work great for moderate-sized ones, but also scale poorly for very large ones. Those are forced to get more creative, with things like dedicated elevator banks for different vertical sections of the building or mid-building transfer lobbies.
Posted Feb 15, 2024 7:26 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (5 responses)
GitHub notifications are far from perfect but this most basic example above shows you did not even try.
> ....At least with email I can set up my own filters
strange you did not try to apply your email filtering skills to GitHub either.
Posted Feb 15, 2024 14:22 UTC (Thu)
by pizza (subscriber, #46)
[Link] (4 responses)
Respectfully, you have no effing clue what you're talking about, or what I did or didn't try.
The problem was that the notifications came from the _organization_ and there was no way for me to turn those off globally. I was able to mute individual issues/threads/whatever, but I still had to do that for each and every new one that landed. There were usually a couple dozen or so a day, coming at all hours (organization had major operations across the US, EU, and SE Asia).
The only ones that could change that situation were the organization admins, who were utterly unresponsive to a lowly peon like myself.
> strange you did not try to apply your email filtering skills to GitHub either.
Pray tell, how can one operate the github web site (or even just its notifications) with an email client? How do you selectively mute most (but not all) notifications on its smartphone app?
And thank you for agreeing that email is superior due to its filtering capabilities!
(and for the record, I did set up email filters to redirect most stuff to /dev/null. That didn't do anything for the app or website notification deluge, rendering those portions of github's user interface utterly worthless)
Posted Feb 15, 2024 20:08 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (3 responses)
So it wasn't you specifically but someone in your organization didn't even try and to make it worse they were in the worst place to do that. That was an obviously stupid misconfiguration, bringing GitHub notifications down to something worse than mailing-lists. That's obviously not the typical GitHub experience - which again is far from perfect but much finer-grained that mailing-lists.
> > > strange you did not try to apply your email filtering skills to GitHub either.
> Pray tell, how can one operate the github web site (or even just its notifications) with an email client?
That wasn't my point.
> (and for the record, I did set up email filters to redirect most stuff to /dev/null.
That was closer to my point.
> And thank you for agreeing that email is superior due to its filtering capabilities!
It _is_ superior! But only for the small, l33t crowd who is very proficient with it and who can't understand why the rest of the world is so wrong not wanting it while burying their head in the sand, not trying to really understand the issues. This is all incredibly sad considering these are some of the smartest people on the planet. "Too smart" maybe; not able to lower themselves down to the level of "normal" people.
Posted Feb 15, 2024 22:06 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (2 responses)
> It _is_ superior! But only for the small, l33t crowd who is very proficient with it and who can't understand why the rest of the world is so wrong not wanting it while burying their head in the sand, not trying to really understand the issues. This is all incredibly sad considering these are some of the smartest people on the planet. "Too smart" maybe; not able to lower themselves down to the level of "normal" people.
Well, maybe, the REASON they are the l33t crowd is because they are using the correct tools for the job! They are superior programmers because they are not using inferior tools!
If you want to be an elite carpenter, you don't make the grade by using a hammer to drive screws. If you want to be an F1 driver, there's no point driving a Cinquecento!
Your average l33t probably does in ONE DAY what your normal person takes a fortnight to do! Do you really think they could be that productive with the same tools your "normal" idiot uses?
That's why I moan at so much software crap today - it's aimed at your sub-par idiot so they can PRETEND to be l33t. Unfortunately, Artificial Stupidity is exactly what it says it is - if you rely on sub par software, you will create sub-par crap with it.
Cheers,
Posted Feb 15, 2024 22:43 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (1 responses)
But making such tools requires a lot of thought, work, time, patience, attention and care and some of those are clearly missing in this instance. "Just watch me zipping through thousands of emails and learn! Why is everyone else struggling? I don't have the time to look sorry, a few more thousand emails to go today..."
> If you want to be an elite carpenter, you don't make the grade by using a hammer to drive screws.
There is zero carpenter using hammer to drive screws; neither noob nor l33t...
Posted Feb 16, 2024 8:26 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Cheers,
Quotes of the week
I think all you need is enabling a git hook:
https://www.kernel.org/doc/html/latest/maintainer/configu...
Quotes of the week
Quotes of the week
https://lwn.net/Articles/961655 DRM-CI: A GitLab-CI pipeline for Linux kernel testing (Collabora Blog)
Quotes of the week
Wol
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
Quotes of the week
Wol
Quotes of the week
Quotes of the week
Wol