Re: [PULL] http://kernellabs.com/hg/~mkrufky/sms1xxx

[Michael Krufky <mkrufky@kernellabs.com>]

On Tue, Sep 1, 2009 at 9:47 AM, Mauro Carvalho
Chehab<mchehab@infradead.org> wrote:
> Em Mon, 31 Aug 2009 07:03:18 -0400
> Michael Krufky <mkrufky@kernellabs.com> escreveu:
>
>> I see the GPIO fix in your git tree now -- Thanks for merging it.
>>
>> However, I also see this changeset:
>>
>> http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=commitdiff;h=31e0ad693fb4e1d1be19dbe1c4f5a1ab9978e810
>>
>> I believe that it is way too late in 2.6.31 to merge a changeset like
>> this -- Please revert that and if there is actually a Kconfig change
>> required, merge a more minimal change for 2.6.31 and hold off this
>> huge, risky change for the next merge window.
>>
>> There is not enough time to fix this, if this changeset causes
>> additional breakage.
>
> This is just Kbuild changes, and it is there at linux-next for some time,
> where for sure people already tried to do several different building tests.
> Among some cosmetics, it removes a dead symbol (DVB_SIANO_SMS1XXX_SMS_IDS).
>
> It is very bad to expose to the user a config option that configs nothing.
>
> Anyway, Linus already merged the pull request. If you eventually find a bug on
> it, please ping me for us to send a fix.
>
> Cheers,
> Mauro
>

The Kconfig symbol names were changed, the target object has changed,
the module filename has changed.

A submenu was added, the USB support is not enabled by default.

None of the above fixed any bug, it just makes unnecessary changes
that are inappropriate this late in a kernel development cycle.

If a bug needed to be fixed, it would have been as simple as adding
the new object file for smssdio.o , and the old
DVB_SIANO_SMS1XXX_SMS_IDS section could have been removed without
changing everything.

I think this is ridiculous to slip in at the last moment, but I would
have had no complaints seeing this in the next merge window.

What is the point of a "merge window" if you let people make such
changes as this right before a kernel is released.

Maybe it all works, maybe it doesnt.  I know I personally am not going
to test this before September fifth, the day Linus plans to release
2.6.31. ..  And even if I do find a problem, how should I know that
the powers that be will act on a regression fix in a timely manner?

Apologies to the users of this driver -- I am not interested anymore.
My time is better spend working on my own code.

On the bright side, I have some really interesting stuff coming.  I
will be posting some RFC's this week that will help to alleviate some
long-standing problems within the media subsystems.  I won't stress
over Siano's driver any longer -- this gives me more time to focus on
the really cool fun stuff :-)

If the kernel's support for this driver becomes broken again, users
can just use the driver that I have posted on kernellabs.com

Cheers,

Mike