くさやは一度だけ食べたことあるのだけど、シュールストレミングやドリアンも出てくる会だったのでくさやが臭かった印象が薄い（シュールストレミングに負けてたため
くさやは一度だけ食べたことあるのだけど、シュールストレミングやドリアンも出てくる会だったのでくさやが臭かった印象が薄い（シュールストレミングに負けてたため
2. How the development process works — The Linux Kernel documentation
https://www.kernel.org/doc/html/latest/process/2.Process.html
U-Boot Development Process — Das U-Boot unknown version documentation
https://u-boot.readthedocs.io/en/latest/develop/process.html
2023/01/24 - よみぽむにっき
https://yomipomu.hatenablog.com/entry/2023/01/24/211356
今気がついたけどよみぽむめっちゃ日記書いてるじゃん
RC がどのタイミングか、というのはプロジェクトのリリースエンジニアリング次第そうなのでなんともだけど、名前のとおりリリース候補となるものなんだから feature じゃないからって積んでいいわけでもない気がする（RC 出したあとに緊急性高い CVE 出たとか動作確認しててやべぇバグ踏んだとかは別
まあブランチングのポリシーは人それぞれなので議論したところで合意に至るのも難しいし、コミッタや primary author が押し通すことになるのも仕方ない面はあるとは思う
feature か fix かで言えば feature だよなぁと。
あと RC 期間中でも dependabot の怒涛の更新が入っていくのはどうなんだ。
まあこれは release branch を切らず main で RC メンテしちゃってるせいだろうけど
https://github.com/mastodon/mastodon/pull/20808
感覚を伝えるために例を挙げるなら、これとかも「新機能」ではないもののバグ修正というほどのものな気はしないので、 RC に入ってからやるようなことか……？ という感じです (まあ最終的にコミッターが正義なのはそれはそうだが)
RCのことRequest Chanceだと思ってないか
バグ修正とデザイン欠陥への対処とドキュメント補強以外のものが RC 以降に追加されるのおかしいから……
そういうのは RC より前のマージウィンドウを用意して入れたいものを先に集めるとか、 alpha や beta で準備してからほぼ固まったリリース候補を出すとか、やりようがあるでしょ……
なぜ Release Candidate になってから変更をガン積みするのか、ｺﾚｶﾞﾜｶﾗﾅｲ
そういえば複式簿記でクレカの2回払 (利息なし) ってどう管理するのがいいんですかね。現状普通にクレカ用の勘定科目に全部まとめて突っ込んでるんだけど、これだと来月の支払いなのか再来月の支払いなのかの区別がクソ面倒なんですよね
