mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Devin Heitmueller" <devin.heitmueller@gmail.com>
To: "Pekka Enberg" <penberg@cs.helsinki.fi>
Cc: "Hans Verkuil" <hverkuil@xs4all.nl>,
	"Markus Rechberger" <mrechberger@gmail.com>,
	v4l <video4linux-list@redhat.com>,
	linux-dvb@linuxtv.org,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	em28xx <em28xx@mcentral.de>, "Greg KH" <greg@kroah.com>,
	mchehab@infradead.org
Subject: Re: [linux-dvb] [PATCH 1/7] Adding empia base driver
Date: Sat, 1 Nov 2008 12:19:14 -0400	[thread overview]
Message-ID: <412bdbff0811010919v3b336939qf94df1162ecbbb28@mail.gmail.com> (raw)
In-Reply-To: <84144f020811010908h1220d209j799edca3eb772fd@mail.gmail.com>

On Sat, Nov 1, 2008 at 12:08 PM, Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> Hi Devin,
>
> On Sat, Nov 1, 2008 at 5:46 PM, Devin Heitmueller
> <devin.heitmueller@gmail.com> wrote:
>> A number of people have suggested that nobody was willing to
>> incorporate Markus's changes incrementally to improve the in-kernel
>> driver.  This couldn't be further from the truth.  I appealed to
>> Markus on multiple occasions trying to find some compromise where his
>> changes could be merged into the mainline em28xx driver.  He outright
>> refused.  It was his contention that his driver was/is better than the
>> in-kernel driver in every possible way, and that the existing code has
>> no redeeming value.  In fact, I was accused of taking his GPL'd code
>> without his consent and incorporating it into the linux-dvb codebase.
>> It's this "all or nothing" attitude that has prevented his work thus
>> far from being incorporated, not the unwillingness of people like
>> myself to do the work to merge his changes in a sane matter.
>
> I'm not sure I understand how he can refuse such a thing. If the code
> is released under the GPLv2 and the author refuses to play by the well
> known rules of the kernel community, then I don't see any problem with
> taking the code and improving the current driver (as long as the
> copyright is properly attributed, of course).
>
> I think it's already pretty well established that we don't just take
> in shiny new drivers and trust a new maintainer to do the right thing
> because that has gotten us in such a mess so many times before. Being
> part of the community is not so much the code you write but the way
> you interact with other kernel developers.
>
> So, if I were you, I'd just do it.

Hello Pekka,

I do not believe that he had any legal standing to prevent me from
taking the code and incorporating it if that was my desire, given that
he released it under the GPL.  However, taking someone's code when
they specifically said they don't want you to is kind of a crappy
thing to do in my humble opinion, and it definitely doesn't improve
relations with the developer.

The reality is that from a technical standpoint I really want Markus
to be the maintainer.  He knows more about the devices than anyone,
works for the vendor, and has access to all the datasheets.  That
said, I don't want a situation where he is the *only* one who can do
work on the codebase because it is poorly commented and structured in
a way where only he can understand why it works the way it does.
Also, I believe certain design decisions should be made as a result of
consensus with the other maintainers, taking into consideration
consistency across drivers.

Regards,

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

  reply	other threads:[~2008-11-01 16:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-01 14:05 Hans Verkuil
2008-11-01 14:36 ` [linux-dvb] " Andy Walls
2008-11-01 15:46 ` Devin Heitmueller
2008-11-01 16:08   ` Pekka Enberg
2008-11-01 16:19     ` Devin Heitmueller [this message]
2008-11-01 16:29       ` Pekka Enberg
2008-11-01 17:55         ` Markus Rechberger
2008-11-01 16:21   ` Hans Verkuil
2008-11-01 16:27     ` Pekka Enberg
2008-11-01 16:51     ` Devin Heitmueller
2008-11-02  4:02       ` Markus Rechberger

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=412bdbff0811010919v3b336939qf94df1162ecbbb28@mail.gmail.com \
    --to=devin.heitmueller@gmail.com \
    --cc=em28xx@mcentral.de \
    --cc=greg@kroah.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-dvb@linuxtv.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@infradead.org \
    --cc=mrechberger@gmail.com \
    --cc=penberg@cs.helsinki.fi \
    --cc=video4linux-list@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®