Brian <[email protected]> writes: > * change the tarball name from "allmydata-tahoe-1.10.zip" to > "tahoe-lafs-1.10.zip" or maybe "tahoelafs-1.10.zip" or > "TahoeLafs-1.10.zip". The #1950 "allmydata"-ectomy would be a > dependency. I'd like the name to be shorter, and to have fewer > hyphens. It's too hard to type right now.
There's already a lot of "tahoe-lafs", so "tahoelafs" is messy and error prone. > * The download URL is too long. The current release lives at: > > https://tahoe-lafs.org/source/tahoe-lafs/releases/allmydata-tahoe-1.10.0.zip > which doesn't even fit into a single 72-column wrapped email line. We > already have "tahoe-lafs" in the DNS name, we don't need to repeat it. > I suggest https://tahoe-lafs.org/downloads/tahoe-lafs-1.10.zip . I > suggest having a "snapshots" or "tarballs" subdirectory of > "downloads/" for the nightly/buildbot ones. And maybe an "old/" > subdirectory for releases older than the last year. Dropping the tahoe-lafs in the path part is ok as long as you are willing to merge other programs also hosted there. In my view, almost all users (once you have a non-neglible amount) get code via packaging systems, and packaging systems want URLs that don't change. As for "older than the last year", if a packaging system hasn't updated, moving the file will break building the package. So I would change that to "has ben obsolete for 18 months", where obsolete means "there are no good reasons not to have updated". > * I think we should stop producing multiple tarball variations > (gz/bz2/zip) and pick just one. Maybe whatever Twisted does. If you do, then make it .tar.gz :-) But seriously, I don't think the extra compression outweights the benefit of being normal. Unix people think zip is icky (and non-standard), and I bet Windows types find .tar.gz awkard. So probably you are stuck with two, which is ok. > * in the longer run, I'd like to produce single-file executables for > non-developer users on major platforms (we might be able to get away > with OS-X/windows/linux), then remove any confusing intrusive config > assistance from the source tree. Basically make the source tree for > developers who are willing to install some dependencies (maybe provide > some pip/virtualenv support to help), have python-dev installed, have > a C compiler, etc. I don't really follow. But the soruce tree should also be aimed at packaging systems, which expect to have all dependencies installed already. IF that's what you mean, fine. I totally ignore the SUMO and 'just download tahoe'. To me, packaging systems are the only thing that matters. Every project thinks it is special, but essentially none of them are special enough to justify individual brain time from users for things that could be handled by pkg_add/etc.
pgpT_9onS9Bv4.pgp
Description: PGP signature
_______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
