Re: [Monotone-devel] Re: Stable Roadmap?

[Nathaniel Smith]

On Thu, Feb 02, 2006 at 11:03:30AM -0800, Graydon Hoare wrote:
> There's "what needs to be done" and "what needs to be done which will 
> cause compatibility / migration events". There's still a fair bit to do, 
> but I believe there are likely only 2 or 3 more possible migration / 
> protocol-compatibility changes on the horizon.

Right... to me, 1.0 basically means:
  -- no giant rough edges or horrible bugs.  Rough edges have been
     disappearing quite steadily, and thanks to the test suite and all
     our horrible bugs generally stay pretty limited, so this is
     unlikely to be much of an issue.
  -- we can be _really really certain_ that our basic data structures
     and stuff are stable, and we will be able to make strong
     compatibility guarantees going forward.  This is the hard part,
     since this requires a really high degree of confidence that we
     haven't missed anything, and furthermore we want to avoid the
     situation where we commit to a format and then advances in theory
     make it obsolete.  (Imagine if we had declared 1.0 back before we
     invented revisions!  Or consider darcs, which _after_ declaring
     1.0 discovered that their fundamental algorithms and data
     structures were flawed and needed to be re-derived from the
     ground up.  Or the various systems that are heading towards 1.0
     without getting renames nailed down...)

Our intention is that the new roster-friendly revision and manifest
formats will suffice for the indefinite future, but I wouldn't be
confident committing to 1.0 on _any_ such format without, say, at
least 6 months of real use burn-in by a diverse group of projects.
But, the actual main coding there is done, so we're moving on to the
next big pieces to stabilize...:

>   - Change to the cert format accompanying work on "management
>     branches", or "ACLs", or whatever we wish to call it. This will
>     probably involve re-issuing all the certs in your database, but
>     probably not involve rebuilding your revision graph.

Right.

>   - Modifications to netsync to support partial-pull operations, which
>     might involve a database migrate command to change the schema and
>     will almost surely involve a netsync protocol-number bump.

I would phrase this instead as "think hard about how to make it
possible to extend netsync in a backwards-compatible way".  Partial
pull is probably not the only change we'll want to make; we should
have some way to do basic feature negotiation or whatever to figure
out whether the other side can do partial pull, or whatever else we
add.

Actually supporting partial pull or not seems less critical, 1.0-wise
:-).

>   - "Future-proofing" of the cert / revision format by including
>     a cryptographic algorithm parameter. Possibly necessary,
>     possibly not. It's entirely possible that discussion will
>     conclude that epochs are sufficient for this problem; we
>     just haven't had the discussion yet.

I'm a bit on the fence here; algorithm agility is mostly useful
for things like SSL, where you call, talk, then hang up.  In monotone,
we never get to hang up, the old data always still needs verifying, no
matter how good this year's attacks are.  So just making full
migration as smooth as possible seems like it might be the only real
option...

It would be nice to migrate to an algorithm whose future prospects
look better than SHA1 before hitting 1.0.  But who knows when
consensus will be reached on that...


So, yeah, basically -- 1.0 is the goal, and we're closer now than
we've ever been, but data and design integrity take time to establish.
So we're working on it.

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco