From: "Krzysztof Hałasa" <khalasa@piap.pl>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Kieran Bingham <kieran.bingham@ideasonboard.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC v2] MEDIA: Driver for ON Semi AR0521 camera sensor
Date: Fri, 25 Jun 2021 08:03:51 +0200 [thread overview]
Message-ID: <m3h7hm4h14.fsf@t19.piap.pl> (raw)
In-Reply-To: <YNSZ4fbboJokxZSx@kroah.com> (Greg KH's message of "Thu, 24 Jun 2021 16:42:41 +0200")
Greg KH <gregkh@linuxfoundation.org> writes:
> I would not waste my time on code that does not have a signed-off-by on
> it, otherwise the developer is obviously saying they do not want to
> merge this as-is.
I would want it be be merged as-is, and would happily supply a SOB, but
nobody would merge it at this point. This isn't a problem, though.
> And I think we all have plenty of code from
> developers that actually want to have their patches merged.
Oh well. I want to have *MY* patch merged. That's exactly why I did what
I did. I did state that I will sign if off when I get positive response,
when the patch is ready to be merged. Isn't it clear?
I almost always sign off my patches. However, this is a specific
situation. Few years ago I published a patch for the same subsystem.
Obviously signed it off etc. It was exactly my SOB that caused it to be
*NOT* merged. Not because it was really bad or something, but because
another developer modified it and the modified patch was given priority.
I didn't object to the modified driver, in fact. I only wanted it to go
through the same process as all other patches, on top of my original
code, to see if it had merit. Guess what.
After all I was told that I had abandoned the code, but it was summer,
I had vacations. I'm starting vacations in a couple of days as well,
will 3 weeks of my absence mean abandonment again?
drivers/media is a fast moving target, catching up will take some time
as well. Abandonment?
Should anyone be surprised that I don't want this story to repeat
itself?
Or, maybe, it's just me. Maybe such actions are good and welcome among
Linux developers? Please answer.
>> Why not? I can put such a text on a book (say, an e-book) as well.
>
> Where would that text be and what would it mean?
Does it matter?
It would be on something that is not a part of the kernel. That's the
point - the SPDX tags may have a lot of meaning in the kernel, and none
outside of it. I can write SPDX-* on a wall of my home and it doesn't
mean it's now a public house.
It was just said that drivers written specifically for Linux (but not
derived from GPLed code) are automatically under GPL. They don't, for
the same reason - the GPL can't define it's scope (nor it claims to);
the author/owner has to do it. At least, it works like that in my
country.
>> > S-o-b is a DIFFERENT thing entirely. Please go read the DCO for what
>> > you are agreeing to there, it is a declaration for what you are doing.
>>
>> Well, that's my position.
>
> That's not what a signed-off-by means, please do not try to make it
> something it is not.
What do you mean?
Chris.
--
Krzysztof Hałasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
next prev parent reply other threads:[~2021-06-25 6:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-22 11:18 [RFC v2] MEDIA: Driver for ON Semi AR0521 camera sensor Krzysztof Hałasa
2021-06-22 11:57 ` Laurent Pinchart
2021-06-23 4:21 ` Krzysztof Hałasa
2021-06-23 4:31 ` Laurent Pinchart
2021-06-23 5:28 ` Krzysztof Hałasa
2021-06-23 13:17 ` Laurent Pinchart
2021-06-23 14:27 ` Kieran Bingham
2021-06-24 4:57 ` Krzysztof Hałasa
2021-06-24 12:10 ` Laurent Pinchart
2021-06-24 12:39 ` Greg KH
2021-06-24 13:22 ` Krzysztof Hałasa
2021-06-24 13:29 ` Greg KH
2021-06-24 14:17 ` Krzysztof Hałasa
2021-06-24 14:31 ` Greg KH
2021-06-24 13:34 ` Laurent Pinchart
2021-06-24 14:42 ` Greg KH
2021-06-25 6:03 ` Krzysztof Hałasa [this message]
2021-06-25 6:59 ` Greg KH
2021-06-24 11:10 ` Mauro Carvalho Chehab
2021-06-24 13:51 ` Krzysztof Hałasa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3h7hm4h14.fsf@t19.piap.pl \
--to=khalasa@piap.pl \
--cc=gregkh@linuxfoundation.org \
--cc=kieran.bingham@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.