On Thu, Feb 01, 2024 at 01:00:10PM +0300, Dan Carpenter wrote:
> This email thread has gone very badly and I'm definitely 50% responsible
> for that. I apologize.
No need to apologize; conflict between ideas is inevitable, and it's not
a bad thing provided we can keep the discussion focused on the
essentials.
> On Wed, Jan 31, 2024 at 01:57:58PM -0500, Kent Overstreet wrote:
> > On Wed, Jan 31, 2024 at 09:43:14PM +0300, Dan Carpenter wrote:
> >
> > > Come on Kent, don't pretend like I haven't pointed out over a dozen
> > > bcachefs bugs since it was merged... I'm just saying the comments
> > > weren't obvious here.
> >
> > Most of them weren't real bugs, just places where I tweaked the code to
> > please the static analyzer; I believe the number of actual bugs was more
> > like 3-4.
> >
>
> That's not true... I really try avoiding make the static checker happy
> patches.
>
> The only one I see which was obviously just to make the checker happy
> is commit 4b33a1916a35 ("bcachefs: bch2_ioctl_disk_resize_journal():
> check for integer truncation") here was my bug report for that:
> https://lore.kernel.org/all/[email protected]/
>
> There were three other patches where it was like we have an "if (ret)"
> but the "ret = " assignment was accidentally left off, but I consider
> those real bugs because obviously the "ret = " assignment wasn't left
> off deliberately.
The list of patches, and what the ratio of real fixes bugs/fixes is, is
honestly not really the relevant point here.
The issue is that it comes in as a trickle, and they all require thought
and back and forth on the list to address given your current workflow,
and they are _not_ high priority bugs - I could safely leave all of them
for the next six months and then address them all at once, given
everything else I have on my plate right now.
But because this is a tool that only you can effectively run, you're
forcing me into your workflow, and that is where I have to put my foot
down. This is _not_ an efficient way of working - and sharing the
results of your tool and not the tool itself is also not terribly in
line with the whole open source thing that the rest of us are doing
here. I'm going to great lengths to make my own code understandable and
useful to end users and other engineers, _not_ something only I can run.
Smatch would be more useful to me if I could just run it myself, in my
own CI, and get results back for new code when I get the rest of my test
results, instead of getting yanked out of my flow a week later to go
abck and look at code I thought I was done with.
I hope that clarifies where I'm coming from.
Cheers,
Kent
