[vdr] next features?

Andrey Kuzmin maillists at egodot.net
Mon Nov 19 10:12:07 CET 2007


> The point is that Klaus has very strict demands on code quality, and
> many patches never get up to that quality level. Thanks to that 
> strictness, the VDR sources are relatively clean and straight 
> implemented, and we're pleased with frequent rock-solid so-called 
> 'developer' releases.

That is very good point for end user to know that he compiled ideal
source. There is some lack of very useful features, but the source is
ideal. Sorry for sarcasm :))

>> Big
>> part of VDR's community also want to "own" it. By ownership I mean
>> here decision making and commiting to CVS/SVN/HG.

> I've never seen an open source project where everyone is allowed write
> access to software repositories. There's always a very small group of 
> people with write access, and any changes go through a strict review 
> process before they're accepted.

I've also told about this, about the group of authorized developers.

But my point was not only authorized developers. My point was make
more than one decision maker. I was really disappointed reading
Klaus's decision not to do anything in H264 field only because he
don't needed it (at least now). And this was not the only one feature
that what denied or delayed because of this reason (remember how much
time takes migration to 2.6.* kernels ;)

> In the end, what we could really need, are some developers that are
> persistent enough to develop their patches to a point where Klaus agrees
> to take over the patch as it is, without the need to do it any better.

How developer should be motivated to do his job, if there will be
"exam of his skills" at the end by only one man with his own vision of
quality of code and what is needed for project and what not? ;)

As I see there are people in this group who wants to participate
in this development. But the rules of this process should be more
clear and open. IMHO.

>And the only thing that I think that could help in VDR development
>is a public bug tracking system, where bugs and feature requests
>could be developed to quality patches.

Exactly. And also voting system, what features are more needed for
community, what less.

>But o.t.o.h. what stops us from doing this in the mailing list?

IMHO this will not work good, because of much reasons like you have to
track mailing list and so on, it will be easier to to check such
bugtracking/voting system from time to time.

P.S. Again, nothing personal. I'm only talking about the process.





More information about the vdr mailing list