[Live-devel] How to contribute code?

[BONNEAU Guy]

Jeremy,

 

Since you already manage an open source project would you be available
to setup and manage an open source public repository for live555. We
could commit the sources as Ross release them since they are of public
domain. I could offer some help if you want. Ross would only need to
setup an URL link in the FAQ section for those people that want an
history browsing of the changes for whatever reason.

 

Guy

 

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Jeremy Noring
Sent: Thursday, June 24, 2010 11:02
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] How to contribute code?

 

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/6ef55793/attachment-0001.html>