[tahoe-dev] tahoe-lafs 1.9.1 shipped in the next Debian stable

[Zooko Wilcox-O'Hearn]

On Fri, Jun 22, 2012 at 12:59 PM, Greg Troxel <gdt at ir.bbn.com> wrote:
>
> I thought tahoe was almost converted to git?

Yes, this will hopefully be the last release that we use darcs.

> Perhaps you could post a tarball that's just like the release,

I'm building a "1.9.2a1" tarball right now. We still intend to change
something to fix #1670, to update some docs, and possibly even some
more changes if we uncover any more serious bugs.

Oh by the way, I just realized that the fix we committed to #1669
might have also fixed #1670. Hm.

> tahoe-lafs has just missed the pkgsrc quarterly deadline for the stabilizing freeze, although a release in the next few days could make it in, since nothing depends on it.

That would be great! I'm eager to get 1.9.2 into as many distributions
as possible because it is the first release which can handle MDMFs
reasonably well. (See
https://tahoe-lafs.org/trac/tahoe-lafs/attachment/ticket/1776/relnotes-and-news.darcs.patch#L55
for details.)

So in a few years, I hope to be able to say something like "Aha!
Everyone has upgraded to Debian 7.0 and pkgsrc-2012Q2, so we can make
MDMF be the default mutable file type in the next major release of
Tahoe-LAFS.".

> But trying to get a release out just before a freeze of some system could be a clue that having more frequent releases along the stable branch (presumably it's always ok) is in order - if it were every 3 months, then rushing to sync with a packaging system wouldn't be an issue.

Yes, that sounds really good to me. Hopefully the new git-based
workflow, and some improvements to our buildbot that Brian and I have
been mulling over, will reduce the amount of human labor and make it
easier to put out releases regularly.

Ideally, there will ultimately be a button labelled "make a new
release", and when you push it you have to choose a version number,
like "1.10.0", and then a few minutes later all the work of making a
new release has been done for you by the buildbot. :-)

The parts that buildbot can't do are documentation such as NEWS.rst,
relnotes.txt, and known_issues.rst.

Regards,

Zooko