Enough people have unthinkingly ackd Davide's message. It deserves some
> 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
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
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.
> BTW, there's nothing forbidding him to write X in form of a patch and
> post it on this list.)
> On the other hand, by forking you'd probably lose
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.
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.
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