Roadmap

  • Zooko's top priority: land the improved servers-of-happiness (docs, share-placement, #1382)
  • make MDMF the default version of distributed mutable files
  • land Lin Shu's work on Server Selection #573
  • land LeastAuthority's work on Cloud Backend #1819
  • improve the error messages, diagnostics, and transparency so that when users aren't getting what they want, they at least get information that can help them (and us) understand why they didn't get what they wanted (#1941)

Leasedb; cloud backend; XSalsa+AES support; virtualenv-based packaging (#2255)

Tahoe-LAFS Python 3 Porting

Goals of This Document

To present the high-level goals and constraints on a project to bring Tahoe-LAFS to Python 3. To provide some detailed technical guidance on how the goals will be accomplished.

Objective

To allow the use of all parts of Tahoe-LAFS on top of a Python >=3.5 runtime while continuing to support its use on Python 2.7. Use of Tahoe-LAFS is defined as:

  • The complete unit and integration test suites pass (as reliably as they do on Python 2.7 and on the same platforms)
  • A Tahoe-LAFS storage node can be created and started via the CLI and services client requests
  • A Tahoe-LAFS introducer node can be created and started via the CLI and services client requests
  • A Tahoe-LAFS client node can be created and started via the CLI and provides storage and retrieval functionality

Development Requirements

The porting effort will follow the existing development workflow for the Tahoe-LAFS project. Roughly:

PRs of diff size under 500 lines are submitted for pre-merge code review

  • One PR corresponds to one Trac issue
  • Changes addressing review feedback are incorporated into the PR prior to merge
  • In almost all cases, changed code should be covered by an automated test.
  • Work is contributed under the Tahoe-LAFS licenses

A number of Tahoe-LAFS dependencies must also be ported to Python 3. These projects are not all under the direct control of the Tahoe-LAFS project and porting workflow must follow conventions or requirements established by those projects.

Porting Principles

The first milestone will be a minimum port. Because Python 2 and Python 3 will be supported concurrently, Python 3-only features (eg “async def”) will be avoided until a later time.

Note: The plan to support Python 2 and Python 3 simultaneously is motivated by the desire to (a) avoid a single huge porting changeset and (b) avoid having the codebase in a broken, partially-ported state for the duration of the porting effort. (a) is informed by our experience with past porting efforts which produced huge changesets that we have never managed to review and merge. (b) is a essentially a necessity due to the other concurrent development happening on Tahoe-LAFS that is unrelated to the porting effort (such development would have difficulty proceeding if Tahoe-LAFS itself did not work during the port).

In dealing with APIs that accept either bytes or unicode, an effort will be made to maintain the Python 2 API. Python 2 APIs that accept str will accept bytes on Python 3. Python 2 APIs that accept unicode will accept str on Python 3. Fixes can be made where APIs are egregiously incorrectly but the types should generally be left the same.

Use the six module wherever it is helpful.

This milestone includes things that are a high priority and desired within the next couple of releases.

Like the 'eventually' category, things in this category are reasonably well-understood and just require sufficient developer time to implement. Even if the fix is not clear, the problem is well-defined.

(The due date is a hack to ensure that milestones are sorted correctly in queries.)

This is for tickets that can't be resolved by releasing a new version of Tahoe that contains a fix: things that don't fit into the Tahoe release schedule. Examples include improvements to Trac, to mailing lists, and to non-Tahoe code, unless these are changes that need to be made in conjunction with a specific Tahoe release.

(The due date is a hack to ensure that milestones are sorted correctly in queries.)

This milestone includes things that we're pretty sure we're going to do eventually, but we're not sure about when.

Things in this category are reasonably well-understood and just require sufficient developer time to implement. Even if the fix is not clear, the problem is well-defined.

This milestone tracks things that we haven't decided about: we're not sure if we should implement them or not. Once we decide that we *will* implement them, they get moved to the "eventually" milestone.

Discussions about future features, crazy half-baked ideas, and vague problems that have not been analyzed yet, all of these go here.

Note: See TracRoadmap for help on using the roadmap.