[tahoe-dev] suggestions for the next release

[Jonathan Dill]

As an outsider I'd say make a homepage on vhost www separate from Trac that is simplified with either tabs or menus in the banner including Downloads.  You can embed content from Trac, you just don't want it to be the main homepage itself, it's like having a Sourceforge project page as the homepage if that makes any sense, somebody like me will look at it but my boss isn't going to look at it and say "yeah, we should definitely use that" it's going to take a lot of convincing.  Have vhost trac.domain or devel.domain for your convenience.


On the filesystem it's fine to make snapshots etc subdirectories of downloads but as a URL there's no reason to force it to be that way snapshots could also be a top level link, otherwise you're defeating the purpose of trying to have shorter links.
—
Sent from Mailbox for iPhone

On Thu, May 2, 2013 at 7:42 AM, Greg Troxel <gdt at ir.bbn.com> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130502/ff591c98/attachment.html>