K. Ryabitsev 🍁
@monsieuricon
Moderator
Posts
2041Following
230Followers
2519This account is for Linux/Kernel/FOSS topics in general: #linux, #kernel, #foss, #git, #sysadmin, #infrastructure.
For my personal account, please follow @monsieuricon@castoranxieux.ca.
Montréal, Québec, Canada 🇨🇦🇺🇦
K. Ryabitsev 🍁
monsieuricon
@ljs @thomy2000 He doesn't want the USSR back, he wants to build the DDR (East Germany), where he spent his early 20s -- with *some* private enterprise, fake pseudo-politicians and a powerful secret service keeping eyes on everything. He now even has a "West Germany" of his own -- the "brothers and sisters" that are "suffering" under the American military boot and who must be "rescued" and re-integrated back into the happy family.
1
1
2
K. Ryabitsev 🍁
monsieuricon
I'm back from the weekend of winter camping with a bunch of scouts and -20°C weather.
0
0
3
K. Ryabitsev 🍁
monsieuricon
@conor Unfortunately, i'm away camping until Sunday afternoon. If you think this is a bug, you should email the tools list.
1
0
0
K. Ryabitsev 🍁
monsieuricon
@cgwalters if by "resistance to change" you mean "not breaking workflows that are extremely efficient for many people", then all of it.
1
0
1
K. Ryabitsev 🍁
monsieuricon
@ArneBab @ekuber @marcan We do have CI via patchwork, it just needs improvement and the Tested-By needs to be recorded in commits.
E.g. see https://patchwork.kernel.org/project/netdevbpf/patch/20230214211534.735718-5-pctammela@mojatatu.com/
E.g. see https://patchwork.kernel.org/project/netdevbpf/patch/20230214211534.735718-5-pctammela@mojatatu.com/
0
1
1
K. Ryabitsev 🍁
monsieuricon
Public-inbox repositories (the data layer behind lore.kernel.org) is not just an archival medium, but also an efficient git-based message distribution platform. You can clone all data behind lore.kernel.org *and* keep it continuously updated.
For example, https://lore.kernel.org/b4-sent/ contains submitted patches there never touched SMTP but were submitted via b4's web submission endpoint. A tool like "lei" is able to retrieve these messages and deliver them to reviewers without any of it touching the much-hated SMTP protocol. Yes, "lei" is a backend tool that is not very end-user-friendly -- the goal is to offer it as a service delivering query-based results into its own public-inbox feed that is available via POP, IMAP, or any other message retrieval protocol, plus fed into patchwork.
Evolutionary change is how we'll improve the situation, not by introducing centralized, single-point-of-failure, outright proprietary or "open-core" tools.
For example, https://lore.kernel.org/b4-sent/ contains submitted patches there never touched SMTP but were submitted via b4's web submission endpoint. A tool like "lei" is able to retrieve these messages and deliver them to reviewers without any of it touching the much-hated SMTP protocol. Yes, "lei" is a backend tool that is not very end-user-friendly -- the goal is to offer it as a service delivering query-based results into its own public-inbox feed that is available via POP, IMAP, or any other message retrieval protocol, plus fed into patchwork.
Evolutionary change is how we'll improve the situation, not by introducing centralized, single-point-of-failure, outright proprietary or "open-core" tools.
1
1
9
K. Ryabitsev 🍁
monsieuricon
My grand plan is to put together a Free Tooling Workgroup at the Linux Foundation that would:
* secure funding for continued work on public-inbox and lei
* secure funding to pay patchwork maintainers to add better CI integration
* secure funding for continued b4 development (so I'm not doing it in-between sysadmin/IT staff management tasks but can make it my primary effort)
* investigate ways to integrate AI into bug report analysis so we can better categorize reported bugs
* slowly and iteratively replace the SMTP component from patch submission and code review, while keeping everything distributed *and* decentralized
I intend to put forth a formal proposal to the Technical Advisory Board in the next few months.
* secure funding for continued work on public-inbox and lei
* secure funding to pay patchwork maintainers to add better CI integration
* secure funding for continued b4 development (so I'm not doing it in-between sysadmin/IT staff management tasks but can make it my primary effort)
* investigate ways to integrate AI into bug report analysis so we can better categorize reported bugs
* slowly and iteratively replace the SMTP component from patch submission and code review, while keeping everything distributed *and* decentralized
I intend to put forth a formal proposal to the Technical Advisory Board in the next few months.
4
8
28
K. Ryabitsev 🍁
monsieuricon
@mort @dm @marcan This has nothing to do with the platform, really. I've reported many (what I consider) critical bugs to Python where they've been sitting in the shiny Github bugtracker without any movement. Your patches are ignored NOT because they were sent via email -- there's just nobody looking at them (because they are on vacation, tired, burned out, sick, etc).
1
0
9
K. Ryabitsev 🍁
monsieuricon
@ljs He's clearly not changing his opinion regardless, so I don't see the point of any continued discussion. It's just going to ruin my day. :)
1
0
2
K. Ryabitsev 🍁
monsieuricon
@captainepoch eh, I made my statement vague on purpose. I think I'll just be more choosy about following or not following some people.
1
0
1
K. Ryabitsev 🍁
monsieuricon
I have a niggling feeling that some people complaining about toxic development communities are actually merely annoyed that they are *differently* toxic from the way they like it.
4
1
8
K. Ryabitsev 🍁
monsieuricon
@raggi @Conan_Kudo @jacksonchen666 @marcan Yeah, but compare this with "you can copy all of linux kernel development archives going back 25 years, and keep them continuously updated, if you like". This is possible with lore.kernel.org -- so I want a similar level of archival and distribution convenience offered for all other kernel development platforms.
0
0
0
K. Ryabitsev 🍁
monsieuricon
@raggi @Conan_Kudo @jacksonchen666 @marcan What about "I want to go back to a discussion that happened 10 years later and still be able to view the entire thing?" And "fetch files by URI" is rife with faulty assumptions -- the "Universal" in "URI" means it's universally addressable, not universally retrievable.
It's a similar problem we already have today with pull requests, for example. If someone sends a pull request and the maintainer rejects it, we have no archive to go back to years later to investigate why it was rejected and what was submitted. I know it's a very niche concern, but as someone who wants to preserve and archive all aspects of kernel development process, I do care about saving this data.
It's a similar problem we already have today with pull requests, for example. If someone sends a pull request and the maintainer rejects it, we have no archive to go back to years later to investigate why it was rejected and what was submitted. I know it's a very niche concern, but as someone who wants to preserve and archive all aspects of kernel development process, I do care about saving this data.
0
0
0
K. Ryabitsev 🍁
monsieuricon
@raggi @Conan_Kudo @jacksonchen666 @marcan Oh, we have lots of standards. It's good, working implementations that are so hard to find. I mean, I just recently discovered that Python's email.message encoders are so broken, it's basically impossible to send a message with headers containing some unicode and not trip up some kind of 7-bit encoding bug.
0
0
0
K. Ryabitsev 🍁
monsieuricon
@raggi @Conan_Kudo @jacksonchen666 @marcan JSON is great until you have to embed a string containing quotes, or some binary content, at which point you're basically doing all the same horrible things you have to do with email messages. :)
0
0
1