这次看新闻真是觉得，Linus又发飙了，话说他一贯的风格就是火爆，但这次的事情似乎更深一点。
你想，他不过是把一段未经过测试的代码给否定掉，理由还挺硬核——完全没有走linux-next那一关，简直就是未完工就寄出的忙乱样。
实际上我也理解，内核代码的严苛程度，没人会质疑。
毕竟，里面一不小心出现Bug，可能会波及亿万设备的正常运行。
试想一下那天Linus发邮件的场景，他大概坐在电脑前，看着那一堆错误信息，心里那个火大——这个定义条件根本不成立，代码根本没跑，就像看到有人把一份毫无校验的‘菜谱’直接交给你做饭。尤其是他点名的那个ad348348，就是纯粹、未经测试就提交的垃圾——话糙理不糙，他也没多给面子。
我自己也经历过类似场景，某次开发中，一个Scroller优化补丁，提交前我其实也没充分测，发现编译就卡在一处宏定义条件不符，那个瞬间真有点想掩面。内核这个层级的项目，没有任何妥协空间。任何一个跳过流程的改动，都可能埋下后续大坑。
你说，为什么Linus会那么狠？其实我觉得，从某个角度看，他更像在维护一份代码信仰。对，他只要代码能在名校教授的严苛考场考试里生存下来，就算推向市场。这次他的话狠得有点出乎意料，甚至可能带点生气过头，但如果你稍微理解他那套标准——这就是个责任感。
这次的事也反映出Linux社区内部，某些项目在流程上的疏漏。我们都知道，提交代码先经过linux-next，类似于预演，发现问题再修，避免问题代码冲到正式版本。这次偏偏有人没走那套流程，直接冲击主线，结果被打脸。
这让我陷入思考：整个工程体系，是否还在沿用七八十年代的管理方式？
不巧的是我之前也在一个研制高可靠性存储硬件团队做过类似的事情，那时我们强调代码走线、严格的测试流程。要是有人拉出未经测试的东西，我们第一反应就是别闹，否则风险太大。而我猜测，Linux大部分开发者也是这样。
只是，随着项目越来越庞大、人员愈发复杂，流程监管变得不那么灵活——任何破坏它的规范的行为都必然被赶出场。
这次的改动包括对拓展设备ID、支持未来生产日期、优化存储删除操作……这些都很常规，比较像点滴升级，没啥爆点。反倒问题出在提交流程上，大概有人以为：反正改几行就行，随手发了。但实际上，这就像盖房子，基础没有打牢，后续装修就乱作一团。
有趣的是，Linus明确表态：不要再发修复版，我觉得他是在强调质量优先。他也说：我不想再收到这种‘未经过linux-next测试’的代码。这其实不只是发火，而是在用高压手段维护整个体系的纪律。
因为他知道，一旦放松，后面就烂泥一样越堆越多。
我下意识归咎到现在工程管理的浮躁，其实就是快插快用的节奏让流程变形了。从早年的单兵作战、到分布式开发环境下的协作，规矩还是得留存，否则就像那天看到一个人乱扔工具在工地上，完全没有安全意识。
更别说内核这种级别，出了问题，都是关乎千亿设备的大事。
刚才我查了一下开源流传的资料，Linux每版推出总会遇到争议——像Lint时的停车场事件，或者那次驱动不兼容硬伤，都是被暴怒引爆的。但每次都能带来质变。
似乎，这次Linus对MMC代码的痛斥也是在帮身边的开发者划清底线。
反映了他的工程良知。因为他深知，代码的品质，是维护开源生态生命线的关键。就像你在厨房里，随便扔点菜进去，或许能短期应付，但要是想长远做出一道好菜，就要严格称量、检验，确保无误。
其实我还在想，未来Linux要不想走下坡——比如谈工程管理，要不要引入更制度化的流程？但一想到压力+自由的精神，环境变得太复杂也不好。这个平衡真难把握。也许，Linus这番怒批，也是出于爱和责任。
下一步，这个MMC模块会怎么走？我偏向于，下一轮版本会更谨慎，理应吸取这次教训——至少提交前运行一次完整的build测试。或许，未来开发流程会变得更像工厂流水线——质量检查环节可不能随意跳过。
（这个话题还可以继续，关于工程流程的改进，或者开源项目中的纪律问题，但我觉得，最核心的还是——任何优秀的技术体系，必须有一种不容妥协的安全阀机制，才能保证它在风雨中屹立不倒。）
Linus的怒火让我意识到，无论技术多复杂，流程多繁琐，责任感永远是最重要的。否则，再厉害的架构也会因为贪快、敷衍而崩塌。能不能有一天，Linux的工程文化真的走上现代化——我不知道，但我相信，这次事件至少会成为一个提醒。
