[RFC] Reorganizing the download directory.

Rob Landley rob at landley.net
Sun Feb 7 00:15:39 UTC 2010


I'd like to do a couple things to http://busybox.net/downloads/

1) Move the actual source tarballs into a "sources" subdirectory (there's a 
lot of them now, makes it hard to see anything else in downloads).

I note that this change is potentially disruptive to people who download via 
script, but it should only have to be done once.  (And we already did it for 
the "legacy" directory with the pre-1.0 versions back when clutter was getting 
overwhelming.)

2) Group the fixes together into a "fixes" subdirectory (so it would now be 
fixes/1.15.2 instead of fixes-1.15.2).

3) Zap Changelog.gz and the "patches" directory.  I stopped updating both back 
during the outbreak of Bruce, and now that things have switched over to git 
there's not much point anyway.

4) Is anybody still using the "qemu" directory (the one with a Red Hat 9 image 
in it for regression testing)?  As far as I know it still works fine, but I 
dunno what our minimum acceptable development environment is these days.

5) Move "README" to "README-busybox" (what updates this, by the way?  Is there 
some kind of commit hook?  Does it match what's currently in source control?), 
and add a new README describing the layout of the download directory.

6) Add a "binaries/$VERSION" directory with prebuilt "not quite allyesconfig" 
busybox binaries for a bunch of different targets, based on the current version 
of the source and statically linked against uClibc.  See 
http://busybox.net/~landley/binaries/1.16.0 for what I'd put there.

Finally, http://busybox.net/download.html seems to fall out of date pretty 
easily (it currently only goes up to 1.14.1), and every single thing on it is 
available somewhere else.  (Either in the downloads directory itself, or in 
the nav bar on the left).  Since I'm proposing to add a README to the 
downloads directory describing the layout of the downloads directory, could 
the nav bar link just go straight to downloads?

Oh, one more question: now that the busybox-cvs list is in git (despite 
http://busybox.net/lists.html still saying "The Subversion server"), does that 
list still serve a good purpose?  I know that mercurial's built-in web 
interface can produce an rss feed of basically anything:

  My FWL project's commit log:

    http://impactlinux.com/hg/firmware/rss-log

  Release history (yeah, my release comments suck):

    http://impactlinux.com/hg/firmware/rss-tags

  An individual files' commit history:

    http://impactlinux.com/hg/firmware/rss-log/tip/sources/trimconfig-busybox

So presumably now that you're using git there's not as much point to a commit 
mailing list?  Would it make sense for the nav bar to link directly to 
http://lists.busybox.net/mailman/listinfo/busybox (which already links to the 
archive page)?

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


More information about the busybox mailing list