From: "Markus Rechberger" <mrechberger@gmail.com>
To: "Thierry Lelegard" <thierry.lelegard@tv-numeric.com>
Cc: linux-dvb@linuxtv.org
Subject: Re: [linux-dvb] RE : [RFC] Let the future decide between the two.
Date: Thu, 25 Sep 2008 14:19:07 +0200 [thread overview]
Message-ID: <d9def9db0809250519m7b21f947o7bb84147d5e70dfe@mail.gmail.com> (raw)
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAJf2pBr8u1U+Z+cArRcz8PAKHAAAQAAAAFWGD+9r2SkGGhLj/rwn00AEAAAAA@tv-numeric.com>
On Thu, Sep 25, 2008 at 2:10 PM, Thierry Lelegard
<thierry.lelegard@tv-numeric.com> wrote:
>> De : linux-dvb-bounces@linuxtv.org
>> [mailto:linux-dvb-bounces@linuxtv.org] De la part de Janne Grunau
>> Envoyé : jeudi 25 septembre 2008 12:48
>> À : linux-dvb@linuxtv.org
>> Objet : Re: [linux-dvb] [RFC] Let the future decide between the two.
>>
>>
>> On Thursday 25 September 2008 08:45:28 Michel Verbraak wrote:
>> [...]
>> > I would like to propose the following:
>> >
>> > - Keep the two different DVB API sets next to one another. Both
>> > having a space on Linuxtv.org to explain their knowledge and how to
>> > use them. - Each with their own respective maintainers to get stuff
>> > into the kernel. I mean V4L had two versions.
>> > - Let driver developers decide which API they will follow. Or even
>> > develop for both.
>> > - Let application developers decide which API they will support.
>> > - Let distribution packagers decide which API they will have
>> > activated by default in their distribution.
>> > - Let the end users decide which one will be used most. (Probably
>> > they will decide on: Is my hardware supported or not).
>> > - If democracy is that strong one of them will win or maybey the two
>> > will get merged and we, the end users, get best of both worlds.
>> >
>> > As the subject says: This is a Request For Comment.
>>
>> This is complete nonsense, distrobution packagers shouldn't
>> decide which
>> API should be used, the API and all drivers should be in the kernel.
>> Having two tree is at best fragmentation and at worst a whole lot of
>> duplicated work.
>
> Having the two coexisting API is a COMPLETE SOFTWARE DESIGN NONSENSE.
>
> This would not be a "cathedral to bazaar" transition, as someone wrote
> on the subject, it would be a "bazaat to mess" transition.
>
> I have no technical opinion on Multiproto vs. S2API since I have been
> using only DVT-T device for the last two years. But I have more than
> 20 years of experience in software design and that would be for sure
> the worst decision ever.
>
> On a user point of view, Janne's point is the most important one:
>> That should a user do if he has two devices which are only
>> supported by one of the trees? That's bad luck?
>
> And this is not only a Multiproto vs. S2API issue. As I mentioned,
> I use only DVT-T devices. I have 4 of them, all working on Linux
> for months or years and there is no one single repository supporting
> all of them at the same time. Most are supported by
> http://linuxtv.org/hg/v4l-dvb, another one needs
> http://linuxtv.org/hg/~anttip/af9015 plus other patches.
> And this is not a transitional situation, it lasts for months.
>
> This is an endemic but unacceptable situation. And, again, this is
> not only Multiproto vs. S2API. IMHO, linux DVB has a real leadership
> problem. There are just too many different forks which could be accepted
> during transition periods (development and validation of a driver)
> but which cannot survive that long.
>
> All these various trees contains technically good code. So, this
> is not a technical problem. Failing to merge them is a leadership
> problem ("cathedral companies" would say a "management problem").
>
> Imagine what would be the kernel today with that kind of methods?
> But for the kernel, there is Linus, a leader that you may like or
> not but that everyone respect (and respect the decisions of). The
> situation in Linux DVB is not like that, unfortunately.
>
> Since Linux DVB is a subsystem of the kernel and since there is
> no undisputed leader in Linux DVB, why not asking for Linus'
> arbitration? He started to get involved AFAIK.
>
look at the wireless framework, sound framework all went through some evolution.
There are around 18 devices supported by multiproto and a few ones
supported by Stevens proposal.
Steven is pulling against the multiproto path which has been available
for years.
searching google for multiproto dvb returns >40.000 hits
for s2api dvb returns 277 hits
or "s2 api" dvb returns 288 hits
Markus
> Currently, all arguments are like:
> - "This API is technically better" (not a technical problem we told you)
> - "Give me technical reasons" (same)
> - "This was voted" (validity of this vote is disputed -> leadership pb)
> - "You don't like me" (personal problems)
>
> One way to get out of this loop is to call for Linus.
>
> -Thierry
>
>
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>
_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
next prev parent reply other threads:[~2008-09-25 12:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-25 6:45 [linux-dvb] [RFC] Let the future decide between the two Michel Verbraak
2008-09-25 6:59 ` Christophe Thommeret
2008-09-25 7:20 ` Markus Rechberger
2008-09-25 10:48 ` Janne Grunau
2008-09-25 12:10 ` [linux-dvb] RE : " Thierry Lelegard
2008-09-25 12:19 ` Markus Rechberger [this message]
2008-09-25 12:45 ` Mauro Carvalho Chehab
2008-09-25 13:55 ` [linux-dvb] RE : " Thierry Lelegard
2008-09-25 17:35 ` Markus Rechberger
2008-09-25 16:40 ` [linux-dvb] " P. van Gaans
2008-09-26 7:47 ` Luca Olivetti
2008-09-26 0:42 ` [linux-dvb] " Andy Walls
2008-09-26 6:44 ` Michel Verbraak
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=d9def9db0809250519m7b21f947o7bb84147d5e70dfe@mail.gmail.com \
--to=mrechberger@gmail.com \
--cc=linux-dvb@linuxtv.org \
--cc=thierry.lelegard@tv-numeric.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