<story><title>Orphaning bcachefs-tools in Debian</title><url>https://jonathancarter.org/2024/08/29/orphaning-bcachefs-tools-in-debian/</url></story><parent_chain><item><author>peppermint_gum</author><text>&amp;gt;not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit&lt;p&gt;It feels like whenever the author of bcachefs comes up, it&amp;#x27;s always because of some drama.&lt;p&gt;Just the other day he clashed with Linus Torvalds: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;lore.kernel.org&amp;#x2F;lkml&amp;#x2F;CAHk-=wj1Oo9-g-yuwWuHQZU8v=VAsBceWCRLhWxy7_-QnSa1Ng@mail.gmail.com&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;lore.kernel.org&amp;#x2F;lkml&amp;#x2F;CAHk-=wj1Oo9-g-yuwWuHQZU8v=VAsB...&lt;/a&gt;&lt;p&gt;My reading is that he&amp;#x27;s very passionate, so he wants to &amp;quot;move fast and break things&amp;quot; and doesn&amp;#x27;t get why the others aren&amp;#x27;t necessarily very happy about it.</text></item></parent_chain><comment><author>ants_everywhere</author><text>Hey at least it&amp;#x27;s not the worst behavior we&amp;#x27;ve seen from a Linux file system creator...&lt;p&gt;I thought Carl Thompson&amp;#x27;s response was very good and constructive: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;lore.kernel.org&amp;#x2F;lkml&amp;#x2F;1816164937.417.1724473375169@mail.carlthompson.net&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;lore.kernel.org&amp;#x2F;lkml&amp;#x2F;1816164937.417.1724473375169@ma...&lt;/a&gt;&lt;p&gt;What I don&amp;#x27;t understand is that IIUC Kent has his development git history well broken up into small tight commits. But he seems to be sending the Linux maintainers patches that are much larger than they want. I don&amp;#x27;t get why he doesn&amp;#x27;t take the feedback and work with them to send smaller patches.&lt;p&gt;EDIT: The culture at Google (where Kent used to work) was small patches, although that did vary by team. At Google you have fleet-wide control and can roll back changes that looked good in testing but worked out poorly in production. You can&amp;#x27;t do that across all organizations or people who have installed bcachefs. Carl pointed out that Kent seemed to be missing some social aspects, but I feel like he&amp;#x27;s also not fully appreciating the technical aspects behind why the process is the way it is.</text></comment>
<story><title>Orphaning bcachefs-tools in Debian</title><url>https://jonathancarter.org/2024/08/29/orphaning-bcachefs-tools-in-debian/</url></story><parent_chain><item><author>peppermint_gum</author><text>&amp;gt;not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit&lt;p&gt;It feels like whenever the author of bcachefs comes up, it&amp;#x27;s always because of some drama.&lt;p&gt;Just the other day he clashed with Linus Torvalds: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;lore.kernel.org&amp;#x2F;lkml&amp;#x2F;CAHk-=wj1Oo9-g-yuwWuHQZU8v=VAsBceWCRLhWxy7_-QnSa1Ng@mail.gmail.com&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;lore.kernel.org&amp;#x2F;lkml&amp;#x2F;CAHk-=wj1Oo9-g-yuwWuHQZU8v=VAsB...&lt;/a&gt;&lt;p&gt;My reading is that he&amp;#x27;s very passionate, so he wants to &amp;quot;move fast and break things&amp;quot; and doesn&amp;#x27;t get why the others aren&amp;#x27;t necessarily very happy about it.</text></item></parent_chain><comment><author>ralferoo</author><text>It&amp;#x27;s very clear from that thread that he doesn&amp;#x27;t understand the purpose of the stable branch. It doesn&amp;#x27;t mean &amp;quot;stable&amp;quot; as in &amp;quot;the best possible experience&amp;quot;, it means it as in &amp;quot;this code has been tested for a long period of time with no serious defects found&amp;quot; so that when the stable branch is promoted to release, everything has undergone a long testing period by a broad user base.&lt;p&gt;If there is a defect found, the change to a stable branch should literally be the minimal code change to fix the reported issue. Ideally, if it&amp;#x27;s a newly introduced issue (i.e. since being on the stable branch), the problematic code reverted and a different fix to the original defect applied instead (or left if it&amp;#x27;s deemed less of an issue than taking another speculative fix). Anything that requires a re-organisation of code, by definition, isn&amp;#x27;t a minimal fix. Maybe it&amp;#x27;s the correct long-term solution, but that can be done on the unstable branch, but for the stable branch, the best fix is the simplest work around. If there isn&amp;#x27;t a simple work around, the best fix is to revert everything back to the previous stable version and keep iterating on the unstable branch.&lt;p&gt;The guy even admits it as well with his repeated &amp;quot;please don&amp;#x27;t actually use this in production&amp;quot; style messages - it&amp;#x27;s hard to give a greater indication than this that the code isn&amp;#x27;t yet ready for stable.&lt;p&gt;I can understand why from his perspective he wants his changes in the hands of users as soon as possible - it&amp;#x27;s something he&amp;#x27;s poured his heart and soul and he strongly believes it will improve his users&amp;#x27; experience. It&amp;#x27;s also the case that &lt;i&gt;he&lt;/i&gt; is happy running the very latest and probably has more confidence in it that an older version. The rational choice from his perspective is to always use the latest code. But, discounting the extremely unlikely situation that his code is entirely bug free, that just means he hasn&amp;#x27;t yet found the next serious bug. If a big code change is rushed out into the stable branch, it just increases the likelihood that any serious bug won&amp;#x27;t have the time it needs in testing to have the confidence that&amp;#x27;s the branch is suitable for promotion to release.</text></comment>