2 ms·

Except he had a history of rushing large changes in at the last minute that were always critical, and would constantly argue about policy during the same time,

Except he had a history of rushing large changes in at the last minute that were always critical, and would constantly argue about policy during the same time, which is not the appropriate time or place. He refused to acknowledge his place on the totem pole and thought he knew better than everyone else, and that they should change their ways to suit his whims.

cogman10 1y ago
The way I read it, it was wrapping in feature and bug fix changes. "We found a critical bug here, to fix it instead of backporting a fix we want to pull in all the code which was built before the bug was discovered". I can understand the motivation. It's a PITA to support an older version of code. But that's not how linux gets it's stability.
- fooqux 1y ago
  That's just bad git hygiene, and lots of lead devs deal with this across the development world. One change per commit/PR please.
  - cogman10 1y ago
    I think it's more natural. Commit A: introduce the bug Commit B: change architecture Commit C: add a feature Commit D: fix A using code present in B and C. The issue ends up being that D needs to be reimplemented to fix A because B and C don't exist on the tip. Since linux has closed windows and long term kernels it means the fix to the same bug could need to be done in multiple ways. Multiple changes per PR is bad, but I assume it's still one change per commit.
    - fooqux 1y ago
      Yeah, but then you run into scenarios where A+D is tested and ready, but B and/or C are not. Git does give you tools to separate them, but most people don't like doing that for various reasons. IMHO, it may be more natural, but only during development. Trying to do a git bisect on git histories like the above is a huge pain. Trying to split things up when A is ready but B/C are not is a huge pain.
- MBCook 1y ago
  He also had bad interactions with other developers, like constantly shitting on other file systems and generally behaving like a jerk completely unnecessarily.
- typpilol 1y ago
  Linux is not known for its stable ABI lol

cogman10 1y ago

The way I read it, it was wrapping in feature and bug fix changes. "We found a critical bug here, to fix it instead of backporting a fix we want to pull in all the code which was built before the bug was discovered". I can understand the motivation. It's a PITA to support an older version of code. But that's not how linux gets it's stability.

fooqux 1y ago
That's just bad git hygiene, and lots of lead devs deal with this across the development world. One change per commit/PR please.
- cogman10 1y ago
  I think it's more natural. Commit A: introduce the bug Commit B: change architecture Commit C: add a feature Commit D: fix A using code present in B and C. The issue ends up being that D needs to be reimplemented to fix A because B and C don't exist on the tip. Since linux has closed windows and long term kernels it means the fix to the same bug could need to be done in multiple ways. Multiple changes per PR is bad, but I assume it's still one change per commit.
  - fooqux 1y ago
    Yeah, but then you run into scenarios where A+D is tested and ready, but B and/or C are not. Git does give you tools to separate them, but most people don't like doing that for various reasons. IMHO, it may be more natural, but only during development. Trying to do a git bisect on git histories like the above is a huge pain. Trying to split things up when A is ready but B/C are not is a huge pain.
MBCook 1y ago
He also had bad interactions with other developers, like constantly shitting on other file systems and generally behaving like a jerk completely unnecessarily.
typpilol 1y ago
Linux is not known for its stable ABI lol