I would like to clarify my earlier comment: I'm not saying LF is not supportive of my work -- in fact, I've always been encouraged to do whatever is necessary to make the Linux development community happy and productive, and there has always been solid backing for it from LF management and fellow IT team members.

However, I do have to manage multiple priorities and my #1 priority remains supporting the LF IT backend infrastructure for kernel.org (plus a few other similarly aligned projects), in addition to managing a small team of fellow IT pros. If I have to choose between working on tooling and working on something that requires attention from the infra side of things, the infra work is always prioritized for practical/operational/security reasons.

So, when I say that "my request hasn't been approved yet" I don't mean it in the sense that someone is telling me not to work on b4 or bugbot -- it just means that we haven't properly reallocated resources to allow me to prioritize tooling work -- yet. To properly request these resources, I need to present a clear vision of what we are trying to accomplish, why it makes sense to work on that (as opposed to, say, just moving things over to some large commercial forge and telling everyone to switch to that), and how this effort helps Linux development in the overall scheme of things. I'm sure we'll get there soon, I'm just explaining why we're not there yet (and hence why some cool stuff I've talked about hasn't made it to b4). :)

@gregkh I'll be happy to split a drink with you over it in S-D, though! :)

@gregkh I don't want to say it wouldn't work for anyone -- it clearly works well for some subsystems. It's just that it's a helluva lot more complicated than throwing together a quick hosted solution and then declaring a flag day of "from this day onward everyone uses this new thing." For every problem we'll solve this way, we'll gain 10 more, not to mention lose some of the more valuable maintainers who are already strained.

@ross not the single-point-of-failure bit. :) I'm watching forgejo's ActivityPub federated features, plus still keeping an eye on radicle.xyz (less so after they chugged the entire pitcher of web3 koolaid at some point in recent history).

@ross both sides have valid and irreconcilable objections -- it's I-don't-want-your-single-point-of-failure-on-proprietary-stack people vs. email-is-terrible-and-lossy-let's-move-out-of-the-nineties-already people.

Sorry for the lack of progress on some of the b4 features -- I've been focusing on finishing up list migrations and planning some long-overdue infra upgrades to happen this year.

Unfortunately, my request to be able to dedicate more time to kernel developer tooling hasn't been approved yet. I need to put together a small report of what we were already able to get done with lore and b4 and what I hope to accomplish if I'm able to dedicate more time to working on it. Without that, there's a perception at LF that I'm just putting band-aids on a process that's beyond fixing and it's better to just move everyone over to GitHub/GitLab instead.

(Yes, I know that 50% of maintainers will vehemently agree with that statement, but I also know that 50% of others will just as vehemently disagree with it. My preferred course of action is iterative changes that would allow integrating forge workflows with the traditional decentralized model without having the whole thing rip apart. Now I just need to put this into words and plans.)

Why does every cautionary dystopian sci-fi tale from the past 75 years somehow become a startup's business plan?

TIL about another community on Slack who is now being asked to pay thousands to preserve basic functionality 😬

Proprietary tools that offer a lot for free, without fail, will squeeze you. And unfortunately, because of their nature, a lot gets left behind when you inevitably migrate.

When we select tools for our communities, we need to think over longer time horizons.

FOSS options like Matrix for chat and Discourse for forums are the better bet.

#Community #DevRel #OpenSource #FOSS #Matrix

@Daojoan you have to read them in their original Klingon.

There's a Russian word "zhabogadyuking" ("frog-rattlesnake-ing") which describes a situation when entities whom you actively dislike are fighting with each other.

@brian Here's ours, probably. It's coming to Canada this year. https://www.vw.com/en/models/id-buzz.html

@brian Annoyingly, charging is one thing Tesla did really well compared to everyone else. Hopefully, we'll soon be out of the "3 different plugs and 12 different networks operating at 5 different KW loads" morass we're currently in.

I still don't like Teslas in snowy subzero temperatures -- some of the design decisions were clearly made by people who have never lived in a cold climate and don't have to worry that there may be solid ice on the door window or door handles may be frozen shut. Our next car will probably be some other EV.

@brian As someone who has owned an EV in Canada for the past 9 years, I call bull on this story. An EV is no less likely to work in cold temperatures than an ICEV.

@gregkh separately as in "in a separate email sent 0.12 seconds later"?

@Cjust it's a great umask for that purpose, though.

@ironiridis @nivex it's probably just a Fastly misconfiguration. If you send an email to helpdesk@kernel.org, I'll try to fix that tomorrow.

@letoams

@securepaul @brauner Yes, this would call the web endpoint, which would do the actual thread retrieval and mailing.

The "watch" part is a bit more involved, because that would require monitoring a thread for updates, but to just send out a thread to an address would be easy.

@brauner @securepaul Stupidly, Gmail doesn't make it easy to put things into your inbox using the API. If I wanted to write a script that would upload a thread from lore into your Gmail inbox, I would need to first get a developer API token (in my name, or in LF's name), then you as a user of my script would need to OAuth, during which Google will say "do you allow Konstantin full write access to your mailbox," the only sensible answer to which is "heck no."