> 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. _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
