[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Are users of Debian software members of the Debian community?



On Friday, 16 September 2022 20:41:33 CEST Chuck Zmudzinski wrote:
> > > The patch is written by Ben Hutchings, a kernel developer.

Anyone can send a patch for inclusion in the upstream kernel:
https://lore.kernel.org/all/20220629224938.7760-1-didi.debian@cknow.org/

IOW: you don't need to have some special 'role' to do it.

> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357#97
> > > 
> > > I don't think I can sign-off on a patch written by Ben Hutchings.

You shouldn't use a Signed-Off 'tag' without someone explicit permission.
You can send the exact same patch with only your Signed-Off tag (required for
patches submitted to the Linux kernel) though ...

> As you can see from the Ben's message, the only question is
> whether the buffer should be increased to 4k or 8k. I tested
> and 4k was big enough for the Xen virtual keyboard, but Ben
> also though that the "correct" value to increase it to might
> be 8k, which matches a buffer size in udev. So we should work
> out that question before submitting upstream, don't you think?

What you can do instead of sending a formal patch is send a normal email
to the persons/lists I mentioned earlier with a *short* description of the
problem (with a link to the bug report) and ask the upstream maintainers
what to do about the problem and whether the limit should be increased 
(in their opinion) to 4k or 8k and whether they think it should be done
at all in that particular source file or whether a different approach should
be pursued and which that is.

If the patch was (really) substantial and written by someone else (Ben),
then it's (way) better form to ask for permission to send it upstream.
In this case, it's only a tiny change (1 'word'), so 'stealing' his patch
should be fine :-)

> > > Please explain why you are asking *me* to do that.

In a do-ocracy, *someone* needs to do it and it may as well be you.

You are also well suited to verify whether a change to 8k would also produce
the desired fix or an alternative fix if the upstream maintainers would
prefer that.

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: