change and be continue to be overtaken in mind-share by other better-run projects which better satisfy a

+

large community of users and developers. See http://www.linuxtv.org/pipermail/vdr/2009-January/019185.html.

−

* [http://www.vdrportal.de/ The Famous VDR Portal, the place to look for patches, plugins, knowledge]

+

A read-only git repository has now been created containing the main releases. This makes it easy

+

for community members to create their own VDR developer trees (by cloning) for management of code and

+

merging of changes. See http://www.linuxtv.org/pipermail/vdr/2008-September/017769.html.

+

+

VDR developer:

+

git clone git://vdr.gekrumbel.de/vdr.git

+

VDR stable:

+

git clone git://vdr.gekrumbel.de/vdr.git stable/1.6

+

You can use 1.0, 1.2. 1.4 for old stable versions too.

+

A copy of the VDR developer git repo and some git-based VDR plugin projects can be found here:

+

http://projects.vdr-developer.org/projects

+

+

Unfortunately no public repository is being ''actively'' used for development of VDR on a patch-by-patch basis. The commits to the git repository are giant code bombs which mirror the tar files on the VDR homepage. This means that the (valuable) granularity of individual patches (and descriptions of them) is not available.

+

+

Hopefully the use of git will continue to increase and the VDR community will become less tolerant of the patch madness that has been prevalent for so long.

+

+

==TODO list==

+

or, what needs to happen coz it's the freakin' 21st century already and splattering plugins, patches and

+

scripts over 50+ websites and several forums and mailing lists is ueberlame:

+

* convince Klaus to use a public source code repository, and to accept and commit patches

+

* bring all the (living) plugins into a _single_ git repo (give commit permissions to their respective authors/maintainers)

+

* set up a single standard (autoconf) build system for all the plugins (select which ones to compile with ./configure --with-[x] options). _This_ is where you do version checking to make sure it all works.

+

* deprecate all the non-committed patches and scripts (i.e. commit them or kill them)

+

+

== External Links ==

+

* [http://www.tvdr.de/ VDR Homepage]

+

* [http://linuxtv.org/vdrwiki VDR-Wiki (english)]

+

* [http://www.vdr-wiki.de/ VDR-Wiki (german)]

+

* [http://www.vdrportal.de/ The Famous VDR Portal, the place to look for patches, plugins, knowledge (german)]

VDR source code repository

Recently there has been renewed talk on the VDR mailing list of creating a source code repository,
so bringing VDR into line with almost all major open source projects, which use repositories such as
git or mercurial to keep track of the many source code updates.
See http://linuxtv.org/pipermail/vdr/2008-September/017659.html.
The original developer of VDR has so far been hesitant to agree, but developers point to a hiatus of
144 days in development and the exodus of users from the VDR camp (mostly to MythTV) as a reason to
modernise the software development process.

As with many personal projects which have reached a certain size there is a choice to be made:
either advance and become a modern open-source bazaar-style project with everything that entails
(source repository, maintainer hierarchy, release schedule, good regular communication), or don't
change and be continue to be overtaken in mind-share by other better-run projects which better satisfy a
large community of users and developers. See http://www.linuxtv.org/pipermail/vdr/2009-January/019185.html.

Unfortunately no public repository is being actively used for development of VDR on a patch-by-patch basis. The commits to the git repository are giant code bombs which mirror the tar files on the VDR homepage. This means that the (valuable) granularity of individual patches (and descriptions of them) is not available.

Hopefully the use of git will continue to increase and the VDR community will become less tolerant of the patch madness that has been prevalent for so long.

TODO list

or, what needs to happen coz it's the freakin' 21st century already and splattering plugins, patches and
scripts over 50+ websites and several forums and mailing lists is ueberlame:

convince Klaus to use a public source code repository, and to accept and commit patches

bring all the (living) plugins into a _single_ git repo (give commit permissions to their respective authors/maintainers)

set up a single standard (autoconf) build system for all the plugins (select which ones to compile with ./configure --with-[x] options). _This_ is where you do version checking to make sure it all works.

deprecate all the non-committed patches and scripts (i.e. commit them or kill them)