[Live-devel] changelogs & patches
hartman at videolan.org
Tue Nov 16 14:44:51 PST 2004
I have learned that easy access to sources is a great drive for
development of a project. I think liveMedia could greatly benefit from
this, as so far VLC and Mplayer and many others have benefitted from
this as well. Still I understand you want to keep as much of the
development under your own wings. It just reduces my desire to work on
On 16 nov 2004, at 01:20, Ross Finlayson wrote:
> I want to be sure that people are downloading and using the complete,
> latest version of the code whenever possible.
From a distribution point of view this is ridiculous of course. Gentoo
or Redhat are completely not interested in using the latest version.
They just want to know if it's compatible with the rest of their
sources, and if it crashes or not. Look at Debian. It WANTS to use an
older version, as long as it's safe for their stable trunk they are
Gentoo is now downloading liveMedia a.o. from videolan.org as the
official liveMedia source, simply because they cannot get it from
> That's why we don't provide version 'diffs' (which can easily be
> misapplied), nor keep old versions of the code available online. Tech
> support can become a nightmare if it's not clear exactly what version
> of the code people are working with.
ehm testprog --version or something?
> For this reason, I also encourage people to - wherever possible -
> *not* make their own custom changes to the existing code, but instead
> to modify/extend the code via subclassing, and use different source
> code directories for your additions.
This is the difference between a bugfix and an addition. To encourage
this is logical, and should be clear to any developer. Actually I think
having a repository to make these changes against would be easier for
these people as well. A clean repository pushes you to work clean and
ordered instead of just hacking sourcecode.
I don't see how the repository form is any harder on the tech support
side than the current one. (except for the fact that there might be
more 3rd party developers).
> That way, the LIVE.COM code can just be replaced, in total, whenever a
> new version is used. (This, BTW, also simplifies peoples obligations
> under the LGPL. By leaving the original code unchanged, and just
> linking against it, your customizations may be kept 'closed source',
> and your product release need only mention the URL of the (unmodified)
> LIVE.COM code: <http://www.live.com/liveMedia/>.
Isn't this a problem of people with closed sources to protect their own
sources? why make liveMedia suffer over it?
> If, for some reason, you feel that you the existing code should be
> modified in some wat to make it easier to extend via subclassing, then
> let me know. (Plus, of course, changes that add general functionality
> will always be considered.)
This is not about subclassing and additions, it's about general code
maintenance. bugfixing, working with ever changing sources (like
liveMedia and VLC are) is a pain in itself, and it's being harder than
it ought to be.
I don't see why you can't just produce date tagged SVN/CVS tar.gz
tarballs. This can even be automated. Just pull sources, append current
date to the version string in the Makefile, and package... You will
always know which version is being used by users of the software.
There is completely no history available, anything can change at any
time without anyone knowing about it. This makes contributing back your
changes back to liveMedia more of a burdon and therefore less likely,
increasing the chances of 'private' forks of liveMedia in my opinion,
instead of encouraging developers to collaborate on a single RTSP
Personally I consider this the difference between an Open Source
project, and sources that are open.
Everybody has his way, and I don't really care about that either, I
just think that the source could benefit from a bit more openness and
that this weighs up to any of the disadvantages.
Derk-Jan Hartman (d.hartman at student.utwente dot nl)
More information about the live-devel