[vdr] [v4l-dvb-maintainer] [Wanted] dvb-ttpci maintainer
lamikr at pilppa.org
Thu Sep 25 23:02:43 CEST 2008
> The basic democratic rules should integrate the community
> and not only two multiproto developers.
> Any way, my compromise for this problem is:
> Manu Abraham and Steven Toth should work on one of the API's (together) and then
> decide which is the better solution for the new upcoming standards!
I agree with those who think that kernel/linuxtv should not try to
maintain both the multiproto and S2API in the long run, that would just
make a chaos. So only one API (preferrable backward compatible) would be
the best option.
I also like that now there is a big push for getting many drivers back to
single v4l-dvb tree instead of tens of different development trees that
makes it impossible for distros to compine a working solution for most of
As a follower of this email list, I however also have small
concern whether the vote between multiproto and s2api was really fair.
There were not any discussion from the API calls and structures used
in different proposals. It did not also help that Mauro who as a
final decision maker with commit rights to v4l-dvb publicly announced over
one month earlier working for S2API instead of multiproto.
But some decision must be made so that the train can get forward and my
understanding is that both the S2API and multiproto API can be used for
that. So in that sense I am happy that the work for getting drivers back
from tens of different development trees back to v4l-trunk has started.
The real win-win solution at least for the co-operation point of view
would be if S2API and Multiproto could somehow be compined for making one
superiour DTV API.
But as there has not been any emails discussing the details of these
two API's I do not know whether it makes sense from technology point of
view. (As the technically best API should always win in Linux...)
I hope people could still have some energy for commenting this?
More information about the vdr