[Live-devel] changelogs & patches

[Derk-Jan Hartman]

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 
liveMedia.

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 
happy.
Gentoo is now downloading liveMedia a.o. from videolan.org as the 
official liveMedia source, simply because they cannot get it from 
live.com

>   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 
library.

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.

DJ
---
Universiteit Twente
Derk-Jan Hartman (d.hartman at student.utwente dot nl)
http://home.student.utwente.nl/d.hartman