[Live-devel] How to contribute code?

[Jeremy Noring]

On Mon, Jun 21, 2010 at 7:50 PM, Ross Finlayson <finlayson at live555.com>wrote:

> I don't use any revision control system myself.  When I'm developing this
> code, I use exactly two commands: "emacs" and "make".
>
> Each source code release - in "tar.gz" form - is less than 500 kBytes in
> size.  These days, that's not a significant amount of data to download in
> order to get the latest revision, and any bandwidth savings obtained by
> downloading from a revision control system instead would be insignificant.
>  And people should not be using any version of the code other than the
> latest one, because that's all that we support.
>

It's not about bandwidth, it's about having a clear history of all changes
made to the project, and when.  It is extraordinarily difficult to isolate
regression without this.


>
> I suspect that the real reason why some people want to use a revision
> control system is that they want to easily update to the latest version of
> the code after they've made custom modifications to it (i.e., without losing
> their modifications).  I'm sorry, but this is something that I explicitly
> want to discourage.  People *should not* be making modifications to the
> released "LIVE555 Streaming Media" code (i.e., inside the "live" directory).
>  Instead, they should be leaving that directory as it is, and instead
> putting their own code in a separate directory (using subclassing, if
> necessary).
>

This is simply not true--I do not want source control so I can "easily
update to the latest version of the code."  I want it so I can easily have a
history of all changes made, readily available diff files, and an easy way
to see when changes have been made.

Furthermore, most programmers *refuse* to use trunk (this is considered
extraordinarily unwise by every decent program I know), which is basically
the policy you're advocating.  The open source project I manage has detailed
download statistics, and the results are clear: people prefer sanctioned
releases as opposed to trunk.  So I'm going to have to disagree with you; I
think your hypothesis here is flat-out wrong.


> If there are parts of the code that make it difficult for people to
> customize via subclassing - e.g., some class members that should be
> "protected:" instead of "private:", then please let us know.


Has absolutely nothing to do with this.  It's more like, the only way I can
get a diff view of the changes made to the project is to cache away the
various releases you put out on a bi-monthly basis into my source control,
so I can do a compare.

I don't expect you to find these arguments compelling, and that's fine--I'll
continue to cache away versions of the library so I can roll back to work
around regression introduced in subsequent releases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100624/3acc388f/attachment.html>