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-boun...@ns.live555.com [mailto:live-devel-boun...@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 <finlay...@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.
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
