[tahoe-dev] suggestions for the next release

[Greg Troxel]

Brian <warner at lothar.com> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130502/8ea183f2/attachment.pgp>