On Tuesday 26 August 2008, Sean Dague wrote: > > On Tuesday 26 August 2008, Phil M Perry wrote: > > > As I said later on in my post, a /private/ source control system > > > available to a single author could still be useful for any nontrivial > > > project, for the very reasons you listed. > > Honestly, if you are going to release the software anyway, the effort to > do a public source tree (when things like github, source forge, and > google code exist) is pretty minimal. The net effect being that people > get to poke at bits between releases.
Agreed, and this is generally what I've been doing -- and I haven't learned how to use 'git-rebase' yet, so my "dirty laundry" of commits that I had to fix later are still public. :-P > Most people won't bother, but the ones that will are typically the ones > you'll actually get useful bug reports or even patches from. Yes; and developers usually want patches against the latest source in the repository rather than a patch against the last stable tarball anyway. On Tuesday 26 August 2008, Phil M Perry wrote: > OK, how's this for a compromise: provide BOTH. Provide a source code > repository for those who want a peek into the latest and greatest, and > provide a Web page with downloadable .zip, .tgz, or whatever for those > who just want a canned solution without all the overhead. I think you may have missed what I had explained earlier; sometimes they're one and the same thing. Since you may not have seen this before, here's a specific example of a Git respository served with "GitWeb": http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.26.y.git;a=summary ... and you'll see that on the right there's a 'snapshot' link, which allows downloading a .tgz file of the source code directly -- of any version you want. It may not be "newbie friendly", but it works. > At a minimum, provide the downloadables, but don't provide only the > source code. Not everyone likes to take on new projects and hobbies -- > sometimes they just want a tool to get a job done. It's usually not that easy to do what you're asking for. Depending on how the software is made, it's often just not that easy to ship a pre-built binary. A dynamically-built binary from C source is likely to differ between Solaris, Linux, and Mac OS X, and definitely *will* be different between computer architectures. Dynamic binaries may even differ between Linux distributions; if I shipped a binary built for Debian Lenny, it probably won't work on OpenSuSE 10.2. :-/ This explains why often the typical install procedure is "./configure; make; make install". Scripts are generally more portable, but in that case the source and the binary are the same thing. -- Chris -- Chris Knadle [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Mid-Hudson Valley Linux Users Group http://mhvlug.org http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug Upcoming Meetings (6pm - 8pm) MHVLS Auditorium Jun 4 - Sqeak! and eToys Jul 2 - KVM (Tenative) Aug 6 - Zenos Sep 3 - TBD
