[tahoe-dev] suggestions for the next release

[Zooko O'Whielacronx]

> * use "1.11" instead of "1.11.0" for the initial release

+1

> * 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.

I'm +ε on this. I'm sure it could benefit from being rewritten, but it
got to be the way it is in part due to feedback from readers. An
important audience for relnotes.txt is people who've never heard of
Tahoe-LAFS before their eye falls upon a release announcement headline
and they click through to relnotes.txt.

There's a lot of "policy" kind of stuff in relnotes.txt that could
perhaps be usefully presented somewhere else. Things like: "we try not
to break backward compatibility", and "we refuse to incorporate
backdoors, even those supposed to be used by law enforcement", "we pay
attention to the buildbot"... Also such a web page or documentation
directory might be a good place for the "thanks to our sponsors"
stuff.

> * 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.

I'd be okay with tahoe-lafs or tahoelafs or Tahoe-LAFS or TahoeLAFS.
For consistency with past usage, that would be "Tahoe-LAFS", but I
admit the hyphen is annoying. It may be too late to fix it, though...

Remember, some people (including me) have this idea that "LAFS" is the
protocol and "Tahoe" is the first implementation – the one written in
Python. Hopefully there will be another implementation someday, making
that idea useful. ;-)

> 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.

+0

> * I think we should stop producing multiple tarball variations
>   (gz/bz2/zip) and pick just one. Maybe whatever Twisted does.

+0, but if we produce just one, it has to be .zip. If you can't
stomach that, then let's do .tar.gz and .zip.

> * Put actual download links all over the site. Emphasize the download rather than quickstart.rst .

I think this is already fixed by, IIRC, Peter LeBek who added a big,
pretty "Download" button to the front page and wrote
https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Installation . (Now at the
moment the quickstart.rst is highlighted at the top of
wiki:Installation, but that's only because all of the packages on
there are still Tahoe-LAFS v1.9.2.)

> * 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.

Well, I'm +½ on supporting binary packages for users, and I'm +1 on
allowing people to be able to use Tahoe without having to deal with
setuptools weirdness, but I'm -½ on taking away people's option to use
it in the setuptools-ey way. I sometimes _like_ being able to do "pip
install allmydata-tahoe". And a lot of other people do, too. For all
of its myriad flaws, it is by far the most popular way to install
Python packages. So if possible I would like to support "setuptools
haters" *without* breaking the way it works for setuptools lovers.

Regards,

Zooko