On 10/11/07, Marcel Siegert <[email protected]> wrote:
> Markus Rechberger schrieb:
> > On 10/11/07, Marcel Siegert <[email protected]> wrote:
> >> Markus Rechberger schrieb:
> >>> On 10/11/07, Aurelien Jarno <[email protected]> wrote:
> >>>> Markus Rechberger a écrit :
> >>>>> On 10/11/07, Linus Torvalds <[email protected]> wrote:
> >>>>>> As such, the old and decrepit em28xx driver seems more useful to
> >> people,
> >>>>>> since at least it supports the limited set of hardware on its own.
> >>>>> it does not since it's broken and feature limited. On the other side
> >>>> I have a device which works perfectly with it if you add the vendor and
> >>>> product ID to the list. I don't really call that broken. And it doesn't
> >>>> need a firmware.
> >>>>
> >>> Aurelien,
> >>>
> >>> the device you're using is around 2 years old. You're one of the lucky
> >>> ones, I have tonns of support mails in my mail account from people who
> >>> own almost a similar device but with different videodecoders which are
> >>> not fully supported in the kernel or which worked and got broken
> >>> during the time.
> >>> It took me around 4 hours to debug such an issue last years remotly
> >>> with an enduser (which includes that noone cared to ask me if I'm fine
> >>> with such an update, neither did someone ask people who own such
> >>> devices that they should test the changes).
> >>> Please also take other devices and upcoming devices into account,
> >>> since i'm willing to spend that time and since I'm in contact with
> >>> various companies who provide several components of those devices.
> >>>
> >>>> Please think that a lot of persons do not have enough knowledge to
> >>>> compile out of tree drivers, and that a lot more do not even know about
> >>>> this out of tree driver.
> >>>>
> >>> this is what all is about, the project does not depend on certain
> >>> broken drivers anymore. And people who initially disagreed without
> >>> having any solution nor contributed any code can continue to play
> >>> their game without having an impact on that driver anymore.
> >>>
> >>> Markus
> >> markus,
> >>
> >> its the same old story you are telling over and over again.
> >>
> >> of course there might be a huge community builded up the
> >> last month @ mcentral,
> >> of course your driver supports newer devices,
> >>
> >> BUT
> >>
> >> the same old story is - and you always miss that part
> >>
> >> we discussed a lot on your changes and also ACCEPTED those
> >> for merging, if you would have changed your UNNECCESSARY touching
> >> of dvb-core. its proven that things could work without that
> >> nacked change to dvb core. but, you decided to stop discussion then,
> >> and went away to perform your own tree/userspace thing.
> >>
> >> as linus and andrew stated within this thread they think they will not
> >> merge your code like it is cause of different reasons,
> >> i am wondering a bit whats your next step is.
> >>
> >
> > I didn't read a clean statement about it. If so I won't continue to
> > pull out opensource drivers from that company.
> > Marcel, you haven't been and you are not into that topic otherwise
> > you'd write about missing parts and address codeparts which I have
> > mentioned in the past which are not ok in the kernel and how to solve
> > that best.
>
> saving my time instead of commenting your code does not mean i am not
> into it. as far as i remember i did say, that the api mixup within
> dvb-core is NOT wanted and there are solutions for other devices,
> that show it can be done otherwise. i must admit it would be a different
> way but the only answer you said was "No, i wont do that"
>
> please go back through the irc logs on linuxtv.org and find the
> appropiate place.
>
> > I remember the mail [1] where you (and Michael) tried to point me to
> > something that doesn't work out. Please get into the whole topic which
> > includes studying the requirements and what parts I'm complaining
> > about.
> as you may remember, i also offered you to ack a MERGE AS IS base for
> your code in a private conversation on irc.
>
I didn't see that.
> the main topics in there have been:
> merge your stuff
> wait for multiproto applied (as i still think it is a better solution)
> rework your stuff to work with multiproto
>
> your answer was afair "i will not allow anyone to modify my code after a
> merge"
>
I would like to see where I wrote that.
I remember that I stated out merge it as it is and modify it
afterwards because then you have to take care about the requirements
which are implemented and which some are not aware of. (There are also
heavy discussions about that ... think we shouldn't rediscuss it and
if someone wants to rediscuss it please put together a wikisite about
the discussions since it makes no sense to get over it again).
> that showed me, others did recognise meanwhile too, that you are NOT
> able to discuss different things or opinions for real, but you take
> your proposals as the "one and only". this can not work, and will not
> work.
>
I am although I won't drop parts of my code in favour of someone who
has different ideas which are not even more complete or don't add some
extra value to it.
Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
