I've been trying to post this for a month, and kept getting the "we are working on resolving issues" error. I thought that there was some bug making me unable to post here anymore. Just noticed that the PNG version that I was trying to upload was 7.8mb, so I guess kbin must have been choking on that.
cacheson
You can use the boost feature. Your boosts are public, but that's usually a good thing. Things you want to save are often things you want to promote, and vice versa.
I dunno, seems kinda bourgeois? Leftist mostly clean their own toilets. They also want to eliminate class stratification, even for those that had conservative parents.
Asking for a ride
AT THE GAY BAR
GAY BAR
GAY BAR
It sounds like you're flirting with "dual power strategy". Would be worth looking into that more and seeing what ideas are already out there. Here's a video that I just pulled up on the topic, seems like a decent introduction:
Sure thing. :)
One day maybe we can have both options
Click on the gear icon in the upper right corner of the page, underneath your username.
From the PR comments:
Maintainers MAY merge incorrect patches from other Contributors with the goals of (a) ending fruitless discussions, (b) capturing toxic patches in the historical record, (c) engaging with the Contributor on improving their patch quality.
I asked around and asked in the C4 specification matrix room.
And the reason is actually simple. If you merge bad code, have a record of proof in git (pull requests aren't forever it's only a github/gitlab thing).So the idea is if you merge bad code you have proof in the git record that there is a bad actor. You can always revert the commit again or fix it. And the record can act as a proof in case the community want to get rid of bad actors.
Hmm, that seems like not such a good look from Ernest. According to google translate:
I know, honestly it was on purpose. I noticed that forks sync changes immediately with /kbin. I wanted to check how they deal with this much-announced community-based qualitative code review. Answer: they can't cope. Quite an obvious bug was accepted in PR and domerged into the main branch :P It now works properly on the rifle ;)
Hopefully everyone can play nice and work together productively.
It looks like they're still working out what they want their process to be:
https://github.com/MbinOrg/mbin/pull/34
Seems like your concern is addressed there:
Pull Requests require at least one (1) other maintainer approval before the PR gets merged (built-in peer review process).
The mbin fork happened when kbin development was looking a lot less active. In any case, it's not necessarily bad to have a diversity of approaches. Due to their differing organizational structures, mbin will likely tend to have more features and more rapid development, but also potentially more bugs, while kbin remains more stable.
Fair enough. Thank you for the transparency and for resolving it quickly.
Did you ever get this working? I set up 23.05 recently on one of my machines, and my Dualsense controllers worked fine though the KDE bluetooth app once I enabled bluetooth in configuration.nix.