Enough people have unthinkingly ackd Davide's message. It deserves some serious criticism. > I'm neither Klaus not a regular of this list, If you say so. > but I think you're not > being fair here: Klaus has every right to say he won't develop on a > community tree; it is, after all, his own free time. BTW, if I remember > well, Klaus has coded several features (i.e. subtitles) he himself said > he didn't use. Several. Is that all? Well ok, we all expect open source development to be driven by personal need, but it is the combination of code created by many people who each had their own needs which is where the magic lies. > Like it or not, VDR is a "cathedral"-style project: this has led to > higher code quality and very good stability Compared to what? A well maintained bazaar-style project is generally thought to produce much higher quality code. Look at the Linux kernel and compare it to any other operating system. > , at the expense of a slower > development pace Yes, a very high cost. > and the lack of some bleeding-edge features in the > mainline. There is no bleeding edge repository, so life at the edge is more difficult for developers than it should be. > If you want those features, you can use a patch posted on this > list (e.g. for hdtv, sourcecaps) or use a plugin (e.g. for teletext > subtitles). All those features should have been included in the main program a long time ago. Sourcecaps I believe has existed as a patch for about four *years* and has it's own web page. Absolutely ridiculous. I am lost for words. > Many distributions include those patches or provide a way > for the user to easily appy them. Yes the distributions unfortunately have to clean things up themselves, and as a result they are far behind the current development. Why should they or you hunt the lists for patches? > Of course, you're also free to develop > your own patches for new features: if they're good enough, Yes, you are always free to do various things, and that is an oft-used excuse in the open source world for various failings. Seriously who will put much effort in if it will their work will languish as a mere patch for a long time? > I'm sure > they'll eventually find their way into the mainline, as it happened, > e.g., with the shutdown handling rewrite some time ago. Eventually is not good enough. How can you be sure enough to make it worth the effort? > You say you want to fork it: what would you accomplish with that? It's > not as if the code would magically write itself. The initial request was for a source repository, not necessarily a fork. Creating a repository would dramatically improve things. After 145 or so days without any release, there is a lot of code which has been posted as patches implementing vital features (such as H.264) which could immediately be merged in. Add to that all the long-standing patches which could be merged in quickly, and a number of the most essential plugins, plus sets of skins/themes/logos, plus some more minor plugins, plus plugins which have fallen into disrepair because nobody has tested them with a recent version. Then fix the makefiles so the config files and plugins actually go in senssible places. I could go on. There are a lot of very quick, very easy wins if a repository is created. And developers will know exactly where the bleeding edge is, and will be able to see clearly what needs to be fixed or can be added. And if a few of the best developers have write access, then things will not grind to a halt when Klaus goes on holiday and he will find that his workload decreases so that it becomes more fun for him. And users will be able to get a usable system up and running quickly without hunting the web for patches and plugins. It is currently *far* too difficult for all but the most persistent people. > I've yet to see a > single prospective developer say "if it were forked I'd write X". Developers just usually don't talk like that. It's too hypothetical. > (And, > BTW, there's nothing forbidding him to write X in form of a patch and > post it on this list.) As above. > On the other hand, by forking you'd probably lose > Klaus, If it were a fork, then by definition it would be without Klaus, but we started off talking about a repository. Klaus is still generally accepted as the leader of the project. The main issue is improving the development techniques he and everyone else uses. > who has written by himself the majority of VDR code and knows it > like no one else. Including the patches? Some of them are almost indispensable. > Finally, I personally fail to see why people switching to MythTV is a > bad thing; As a VDR user you really should care! VDR only works as well as it does because so many people have taken an interest in it, tested it, provided feedback, written patches and plugins, and promoted it. A project needs continual attention if it is to continue working well. If the interest falls then it will not be updated to work with updates to the libraries it depends on, and updates to the Linux kernel (the DVB API for example). Bug reports will not be made, and neither will fixes, let alone any new development. Eventually it really will stop working. > VDR is not a religion, I think everyone should use whichever > software he thinks suits best his needs. I'm very happy with VDR and > won't be switching anytime soon. > > Davide At this point I think someone will create a VDR repository anyway. If Klaus wants to be the leader and lead maintainer then the door is wide open to him, for now. Not improving things is indefensible in my opinion. Regards, Hans -- Release early, release often. Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
