On Sat, 14 May 2022 09:31:23 -0700
Joe Perches <joe@xxxxxxxxxxx> wrote:
> On Sat, 2022-05-14 at 16:53 +0100, Jonathan Cameron wrote:
> > On Tue, 10 May 2022 08:47:33 -0700
> > Yury Norov <yury.norov@xxxxxxxxx> wrote:
> >
> > > bitmap_weight_{eq,le} is better than bitmap_weight because it
> > > may return earlier.
> > >
> > > CC: Jonathan Cameron <jic23@xxxxxxxxxx>
> > > CC: Lars-Peter Clausen <lars@xxxxxxxxxx>
> > > CC: Michael Hennerich <Michael.Hennerich@xxxxxxxxxx>
> > > CC: linux-iio@xxxxxxxxxxxxxxx
> > > CC: linux-kernel@xxxxxxxxxxxxxxx
> > > Signed-off-by: Yury Norov <yury.norov@xxxxxxxxx>
> > without being cc'd on the cover letter, there is no obvious way for
> > me to know this is reliant in some series to be found in next.
> >
> > Please call out the exact dependency and whilst it's a long list,
> > it is good to cc all people cc'd on individual patches also
> > on the cover letter so they have that background information.
>
> When doing a treewide change like this, vger would commonly
> reject the message because of too many recipients.
Hmm. I took a look via lore before sending this moan and didn't think
this actually had that large a list of CCs but maybe my counting wasn't
great (lots of overlaps between different patches).
The series is also not a tree wide change.
It's a set of changes related only by the fact they are using
a call to the same set of functions and the series is based
on next (which is usually a bad idea as a tree to base anything on).
Arguably there are two different sets of functions at that (the bitmap
ones and the cpumask ones)
This is a good set of changes, but taking it slowly and sending these
out as a number of different series after rc1 would have made
much more sense to me. That way visibility would have been good
and they could have been applied through the various individual trees.
If there is a reason to want to take this via a common tree then
that information needs to be conveyed to all the subsystem maintainers.
Jonathan
>
> >
> > Change seems fine, but I've no idea when/if to pick it up because of
> > that lack of information.
>
> You could try using lore with the in-reply-to message header id
>
> https://lore.kernel.org/lkml/20220510154750.212913-6-yury.norov@xxxxxxxxx/
>
> that gives you the entire thread.
>
