Re: What's cooking in git.git (Jan 2025, #06; Wed, 22)

From: Jeff King <peff@peff.net>
Date: Feb 4, 2025, 02:35 UTC
Message-ID: <20250204023518.GA23954@coredump.intra.peff.net>
In-Reply-To: <xmqqo6zjyw4a.fsf@gitster.g>

On Mon, Feb 03, 2025 at 05:51:33AM -0800, Junio C Hamano wrote:

Show 6 quoted lines

> After seeing a few of your messages that begin with "Coverity
> complains ...", I appreciate them a lot.  Earlier I was naively
> hoping that triage-and-hand-off-to-original-author would be much
> less work but no, we very much need to somehow find a way to push
> the triaging part to individual topic authors or this thing will not
> scale.

Yeah, there's definitely some human intelligence needed to pick apart Coverity (and I probably only end up reporting a portion of what it mentions; some are just nonsense, and some are old and probably unimportant issues).

OTOH I basically end up triaging them when they hit 'next' anyway. So unless there are a lot of topics that hit 'jch' but never make it to 'next', it's really just moving the workload around in time.

The thing that would increase workload is if I end up spending time on patches whose issues would have been caught during regular review (or maybe even already were, racing with them making it into 'jch').

Show 9 quoted lines

> Perhaps I can control the rate of topics that trickle into 'jch'
> from 'seen' to keep them a bit more manageable somehow?
>
> If an iffy topic that begins its life in 'seen' gets rerolled number
> of times while there, but after the final reroll before getting
> merged to 'jch' (because it was marked as "Will merge to 'next'?" or
> better in the What's cooking draft), it never gets rerolled until it
> hits 'next', then your workload would not change compared to the
> days back when you built yours on 'next'.

So, yeah, this. The rate of topics entering is not so big a deal as the quality of topics when they make the transition to jch. As you note...

> Of course, the question then becomes "who will vet these topics so
> that they do not need a big reroll before it hits 'jch'?", and we
> are back to square one?

..this work still has to happen somewhere. But I think people reviewing and discussing patches is one way that the load is spread out. If review settles down on a topic then maybe that's a sign it's ready to be looked at.

Of course the effort to look at Coverity could be spread out, too. It's just hard to do because their interface is closed-ish (everybody needs to make their own account, we can't share links, etc). And also because there's a coordination problem. I mostly look at the "new defects since the last build" list since there's so much old noise. But I don't know how I'd mark an uninteresting issue as "I looked at this, and nobody else needs to".

I guess if we had a bot that sent a summary of Coverity results to the list, that thread could be a central point for discussion. But their notification emails have no details; most of the richness is in their web interface. I think it would be hard to condense that into an email that would be useful to people. But maybe I could mine it with a script or something.

I dunno. I think there are possibilities there, and if the results were incredibly useful I'd be more excited about spending time on it. ;) For now let's try it with me following jch and see how that goes.

-Peff