On 02/05/13 02:34, Brian wrote: > > While going through the mechanics of today's 1.10 release, I came up > with a list of things I'd like to change for the next one. What do you > think? > > * use "1.11" instead of "1.11.0" for the initial release
+0 > * rewrite "relnotes.txt": it's almost entirely boilerplate, and (being > in the source tree) cannot contain strong identifiers like hashes of > the release tarballs or the git revision id. What I've done for other > projects is: one paragraph of download pointers to the new release, > one paragraph summarizing what is new or fixed, and one paragraph > explaining what the project does (the last paragraph remains the same > between releases). Maybe just check in a template, instead of the > final text. +1 > * 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. +1, but this should happen at the same time as changing the appname. (The directory inside the tarball is named after the appname anyway.) > * 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. +1 > * I think we should stop producing multiple tarball variations > (gz/bz2/zip) and pick just one. Maybe whatever Twisted does. .zip is convenient for Windows users, but inconvenient for Unix users. I don't see that it actually costs us very much to provide all three. > * Put actual download links all over the site. Emphasize the download > rather than quickstart.rst . My argument is that getting a potential > user to download something represents committment: they've already > stopped to look, and done the "hard" part of getting a tarball, now > they're more likely to spend a few more minutes opening up the tarball > and looking for a README or an INSTALL file. +1. (The current front-page download "button" actually points to <https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Installation> which is another questionable indirection, especially as the OS packages don't actually get updated immediately.) > * 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. Unsure, I'd have to see a more concrete proposal. I don't particularly like the idea of partitioning what developers do from what users do, since then developers won't be testing the user packaging in the course of normal development. -- Daira Hopwood ⚥ (formerly David-Sarah)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
