[tahoe-dev] suggestions for the next release

[Daira Hopwood (formerly David-Sarah)]

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)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130503/40f887d9/attachment.pgp>