If you split all the changes for a feature this way not only you hide the way all changes interact with each other but also make the development at least 10x longer because an average approval time is often more than a day.
This will be accompanied by the sort of dev manager that thinks a KPI for "number of PRs merged" won't in any way be gamed or backfire.
I don't know what they're doing where you can do code reviews in 5-10 minutes, but in my decades doing this that only works for absolutely trivial changes.
The goal here is to make almost all CLs trivial enough that they can be reviewed quickly. You can compose almost any feature out of many small simple changes.
Yes, and you can waste a ton of a coworker's time doing it.
Say you're upgrading to a new library, it has a breaking change to an API. First, add `#if`s or similar around each existing change to the API that check for the existing library vs the new version, and error if the new version is found. No behavior change, one line of code, trivial PR. One PR per change. Bug your coworker for each.
Next, add calls to the new API, but don't actually change to use them (the `#if`s won't hit that condition). Another stack of trivial PRs. Your coworker now hates you.
Finally, swap the version over. Hopefully you tested this. Then make a final PR to do the actual upgrade.
For something less trivial than a single breaking upgrade, you can do the same shit. Conditionally compile so that your code doesn't actually get used in the version you do the PR in, you can split out to one PR per character changed! It'll be horrible, everyone will hate you, but you can split changes down to ridiculously small sizes.
I should add that the idea complexity relates to LoC is also nonsense. Everyone that's been doing this for a while knows that what kills people are those one line errors which make assumptions about the values they are handling due to the surrounding code.
I think approval time would take much longer. The issue is that while actual time spent in review may be shorter, there's a lot of context-switching time costs that increase with the number of PRs submitted.
No one on the team is just sitting there refreshing the list of PRs, ready to pick one up immediately. There's a delay between when the PR is marked as ready and when someone can actually get to it. Everyone is trying to get work done and have some time daily in flow state.
Imagine you have a change; you could do it as one PR that takes 1 hour to review, or 3 small PRs that each take 15 mins to review. The time spent in review may even be shorter for the small PRs, but if each PR has a delay of 1 hour before a reviewer can get to it, then the 3 PRs will take almost 4 hours before they're done, as opposed to just 2 hours for one big PR.
I don't think that's a realistic view of the timeline. I've done features as multiple PRs and there are really two cases:
1. I can't submit pieces until I have the final version. PRs go up at the same time and can be reviewed one after another immediately.
2. There's a very specific split that makes that feature two features in reality. Like adding a plugin system and the first plugin. Then the first part gets submitted while I still work on the second part and there's no delay on my side, because I'm still developing anyway.
Basically, I've never seen the "but if each PR has a delay of 1 hour before a reviewer can get to it," getting serialised in practice. It's still either one time or happening in the background.
It's because an average Apple engineer has to enter his password at least 10 times a day and it's kind of no big deal for them. Source: I was an Apple eng.
Jellyfin is not able to group series together and on top of that shows everything in random order, why bother with it when there are alternatives that can do that?
Actually after reading it more carefully I probably see why it didn't work for me, but the notes in the page are bizarre:
* Avoid special characters such as * in M*A*S*H, use MASH instead.
Since when a common ASCII character is a special one? What about more common unicode characters I use?
* Do not abbreviate the Season folder with S01 or SE01 or alike.
I.e. if I put anything not in the folder named "Season XX" it won't work? Ugh... really?
* Season folders shouldn't contain the series name, otherwise Jellyfin can in certain cases (Stargate SG-1 due to the dash and one, for instance) misdetect your episodes and put them all under the same season.
Well, how about to fix it?
* Episode numbering for specials may vary from metadata provider to metadata provider.
Very helpful, so the "Series XX" required above won't always work.
And even if everything above fails why not to sort by name? It should not be hard for any engineer, right?
I have one folder with movies and series. It shows as a randomized mix, maybe it uses something like modification time by default? It's definitely not by name.
I have the series in their own folders. I tried to do a more nested structure to no avail. After a day of attempts to fix it I switched to Plex and it despite having its own quirks just worked fine.
XMPP was not a mobile friendly protocol for a while, had efficiently no security out of the box and lacked simplest things like image or other file transfers.
Awhile ago. XEP-0286 (mobile connection improvements) dated 2018-01-25. File sharing has many different XEPs and I have no idea which works, but I know that early XEPs usually didn't work because of NAT. XEP-0384 (encryption) dated 2022-01-18.
All of those are newer XEPs for things that existed long before those XEPs or those specific versions if the XEP were published. There may be specific issues (I do remember that p2p file sharing never worked unless you were a network engineer who could tame nat), but I'm skeptical that they were still an issue when other protocols came along. I could be wrong, of course.
And nowadays it faces a marketing issue because it's extensible, so none of those problems go away because a solution exists somewhere.
"Hey, I want to set up a modern messenger."
"Sure! Here's XMPP, the ten extensions you need to enable and configure (problem left as an exercise for the reader), and the seven ports you need to open!"
"... Okay? A Matrix node is apparently a drop-in solution; I'm gonna use that."
XMPP is in desperate need of a Docker image that Just Works and the wizard to set up that Docker image. And then you need users savvy enough to have their clients configured correctly.
Ironically I think the absolute opposite. An XMPP server is something I can install on my ten year old home server without a second thought ( you have several to choose from even in debian's repositories) and expect it to work with minimal config.
Matrix servers? You have mostly one implementation to choose from and it comes "packaged" as a monster container with several python modules likely already with CVEs and god knows what else. And then the resource usage...
Yeah, it's great. One package that works and already knows all its dependencies. And thosev exploring the CVEs should generally find themselves in a chroot jail so not too much to worry about.
Yeah, Snikket looks like what I'm looking for. I didn't find it the last time I tried this; I went the "install what dpkg can see" route and that went poorly.
What servers don't have good defaults these days, and what clients need any configuration at all beyond the username and password? I don't think this is true.
Also Snikket meets your Docker requirements if you're into containers.
The last time I tried to get jabberd set up on an Ubuntu install, the port-opening and config became a nightmare and induced me to give up. No good signal on why it wasn't working.
oh interesting, fair enough; I didn't know jabberd still existed! FWIW, Prosody, Ejabberd, OpenFire, etc. all mostly have sane defaults for a basic chat system (both in terms of performance and features). They won't be an exact match of course, but all the basic stuff should be there.
Removing stop words is usually a bad advice which is beneficial only in a limited set of circumstances. Google keeps all the “the”: https://www.google.com/search?q=the
Heh I guess that's a good point. All I have is a ten year old iPhone just to run Cisco DUO for work and there seems to be no way to run llama.cpp on it even with a very small model.
Occasionally I'll use i.sh to ssh into a decent computer but it would be nice to be able to just run normal software on it.
