[lkml]   [2009]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PULL]
    On Tue, Sep 1, 2009 at 9:47 AM, Mauro Carvalho
    Chehab<> wrote:
    > Em Mon, 31 Aug 2009 07:03:18 -0400
    > Michael Krufky <> escreveu:
    >> I see the GPIO fix in your git tree now -- Thanks for merging it.
    >> However, I also see this changeset:
    >> 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



     \ /
      Last update: 2009-09-01 17:05    [W:0.032 / U:75.056 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site