how to land magic-folders?

Zooko Wilcox-O'Hearn zookog at gmail.com
Wed Apr 6 20:42:42 UTC 2016


Unfortunately I didn't see this until I read about it in TWN
(https://tahoe-lafs.org/~marlowe/TWN62.html). This, along with about
half of the emails from tahoe-dev and trac, were in my spam folder in
gmail. ☹

On Fri, Apr 1, 2016 at 11:44 PM, Brian Warner <warner at lothar.com> wrote:
>
> I'd like to hear from Daira and Zooko (and everyone else involved), but
> it sounds like the magic-folders branch might be 1: sufficiently
> isolated, and 2: sufficiently functional, that we could land it now and
> just mark it as "Experimental" without causing anything to explode. If
> so, that'd be great, as then the folks hacking on it could do their
> continued work on a much shorter branch that should be a lot easier to
> maintain (and merge from trunk, or rebase, or however they choose to
> manage it).

That sounds like the right move. I think the "sufficiently functional"
part is very far along, and it is super-high-quality code. The only
reason not to commit right now to making it a non-experimental feature
in the next release is that we might want to change the
protocol/data-formats to enable > 2 writers and/or to add a permanent
history of old versions [1].

If we committed to making it a new feature, we'd no doubt want to
engage the Tahoe-LAFS tradition of maintaining backwards compatibility
for a few releases to allow everyone to upgrade. So the only reason to
hesitate to commit to Magic Folders now right now is if the current
protocol/data-format would be a millstone to support when extending
Magic Folders in the future.

I'm not sure whether the current protocol/data-format is already good
enough and extensible enough to ease this hesitation. Daira probably
has a clear idea about whether it could be conveniently upgraded to
those potential future features in a backwards-compatible way.

Sincerely,

Zooko

[1] https://tahoe-lafs.org/pipermail/tahoe-dev/2016-January/009664.html

P.S. I still think it would be a project-management mistake to jump
right into bundling a permanent-history feature into the Magic Folders
feature. Some users — maybe even most of them — would actually want
the opposite — deletable files, and even for those users who want
permanent history, I think it could easily take many months, perhaps
years, of development for it to be at the level of maturity and
readiness that today's Magic Folders is at. That doesn't mean we
shouldn't add an optional permanent-history feature *after* shipping
the current Magic Folders implementation.


More information about the tahoe-dev mailing list