03/02/2022 21:21, Aaron Conole:
> Thomas Monjalon <tho...@monjalon.net> writes:
>
> > Aaron, David,
> > Please could you review this patch?
> > Thanks
> >
> > 13/01/2022 13:41, Josh Soref:
> >> On Thu, Jan 13, 2022, 6:42 AM Thomas Monjalon <tho...@monjalon.net> wrote:
> >>
> >> > Hi,
> >> >
> >> > The explanation should be in the patch, not the cover letter.
> >> > Actually, you don't need a cover letter for a single patch.
> >> > Copying it here:
> >> > "
> >> > dpdk is fairly expensive to build in GitHub.
> >> >
> >> > It's helpful to abandon old builds as soon as there's a new
> >> > build waiting instead of wasting resources on the previous
> >> > round.
> >> > "
> >> >
> >> > 12/01/2022 07:50, Josh Soref:
> >> > > Signed-off-by: Josh Soref <jso...@gmail.com>
> >> > > ---
> >> > > + concurrency:
> >> > > + group: build-${{ matrix.config.os }}-${{ matrix.config.compiler
> >> > }}-${{ matrix.config.library }}-${{ matrix.config.cross }}-${{
> >> > matrix.config.mini }}-${{ github.event.pull_request.number || github.ref
> >> > }}
> >> > > + cancel-in-progress: true
> >> >
> >> > The goal of the CI is to catch any issue in a submitted patch.
> >> > Is your change cancelling a test of a patch when another one is
> >> > submitted?
> >> >
> >>
> >> If it's on the same branch or if it's in the same pull request yes,
> >> otherwise, no.
>
> We currently have a report on every patch, which helps us when a patch
> series has a breaking failure in the middle and then fixes it in a later
> patch. With the mechanism you have here, we lose that ability - it is
> important to have, as a `git bisect` can be broken without this feature.
Good point.
> How much of a problem is this in practice? I want us to be good
> citizens, but also I don't want to lose the bisect-ability of the
> series.
Bisectability is important.
So we have to reject this patch, right? Or any other idea?
