[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: merge struct block_device and struct hd_struct
On 18.11.2020 10:09, Greg KH wrote: > On Wed, Nov 18, 2020 at 10:04:04AM +0100, Jan Beulich wrote: >> On 18.11.2020 09:58, Christoph Hellwig wrote: >>> On Wed, Nov 18, 2020 at 09:56:11AM +0100, Jan Beulich wrote: >>>> since this isn't the first series from you recently spamming >>>> xen-devel, may I ask that you don't Cc entire series to lists >>>> which are involved with perhaps just one out of the many patches? >>>> IMO Cc lists should be compiled on a per-patch basis; the cover >>>> letter may of course be sent to the union of all of them. >>> >>> No way. Individual CCs are completely broken as they don't provide >>> the reviewer a context. >> >> That's the view of some people, but not all. Context can be easily >> established by those who care going to one of the many archives on >> which the entire series lands. Getting spammed, however, can't be >> avoided by the dozens or hundreds of list subscribers. > > kernel patches are never "spam", sorry, but for developers to try to > determine which lists/maintainers want to see the whole series and which > do not is impossible. > > Patches in a series are easily deleted from sane mail clients with a > single click/keystroke all at once, they aren't a problem that needs to > be reduced in volume. This doesn't scale, neither in the dimension of recipients nor in the dimension of possible sources of such series. While it may seem small, it's also a waste of resources to have mails sent to hundreds of even thousands of people. So while from a technical content perspective I surely agree with you saying 'kernel patches are never "spam"', they still are from the perspective of what "spam mail" originally means: Mail the recipients did not want to receive. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |