Re: [Monotone-devel] Re: pretty pretty pictures (for some value of pretty)

[Nathaniel Smith]

On Thu, Sep 14, 2006 at 03:17:32PM -0700, Rob Schoening wrote:
>    <<I still think monotone is the best open-source VCS/SCM around>>
>    I'll definitely second this.
> 
>    As a monotone user reading this list fairly consistently, I actually think
>    that monotone is *MUCH* closer to being at a v1.0 state than the core
>    development team might think.  So oddly, every time new features get
>    discussed on this, I find myself a bit disappointed....only because the
>    feature set that's already there is nearly sufficient.

Well, that's fair.  We should be clear about what we're doing and
why.

"1.0" worthiness basically has 3 components: robustness, utility,
stability.

Robustness is too important to put off until 1.0; so we've been
basically 1.0-worthy here for a while.

Utility is the hardest to achieve, because you have design new things,
find bugs in them, use them, get user feedback on them, and then
iterate the whole process over and over.

Stability is in some sense the easiest -- just stop working, and
nothing will change! -- but it fights with utility, because if you
want to make things better, you have to keep changing them.  It also
fights with robustness, because sometimes you will discover you have a
bug you want to fix, but you can't without breaking compatibility.

So reaching 1.0 is mostly an issue of stability.  Basically, when we
call something 1.0, that's a commitment that we will stop breaking
compatibility; and we don't want to do that until we are confident
that this commitment won't cripple our long-term usability.

Consider that if we had called 0.25 version 1.0 instead, then we
_could not_ have switched to rosters.  This would have been a Bad
Thing.

Well, in practice, we probably would have had to switch to rosters
anyway because of the subtle but insoluble robustness issues with the
old history format.  But that would mean that we lied to our userbase
when we told them we had reached 1.0, and that's not a very
forgiveable sort of lie, even if done in good faith.  This isn't a
very hypothetical story, either; it's basically exactly what happened
to Darcs -- they released 1.0 and _then_ discovered that their history
model was fatally broken, possibly unfixable.  (I'm not trying to bash
the Darcs team here -- quite the opposite.  I can imagine doing
exactly the same thing all to easily, and it makes my stomach cramp in
sympathy.)

So, we've been clawing our way towards a system that we can have that
kind of confidence in -- somewhat slowly, since we're having to make
pretty much everything up as we go.  A major part of this work came
when rosters landed -- this is when we stuck in version numbers on
the data formats, for instance, you might have noticed :-).  I think
we are currently pretty comfortable with the idea of preserving the
current revision and manifest format indefinitely (except for
upgrading the hash from SHA1 at some point), with at most backwards
compatible changes.  (We aren't _committing_ to doing this yet, of
course -- that's what "1.0" would mean.)

The major barriers to 1.0 at this point are trust, certs, and netsync
-- we know all of these need some sort of compatibility breaking
transition to reach something that will be indefinitely maintainable.
This is why you might see references to the policy branch work as "the
last feature" -- once we get trust and certs solid, monotone _per se_
is done.  Hopefully.

Of course, we also keep working on improving UI, fixing bugs,
reducing resource usage, etc.  Partly because this, well, helps the
real people who are using monotone now :-).  Partly, though, because
when you get down to it, usability is really the only goal; deep
systemic changes are ultimately motivated by usability too.  (E.g.,
check how many of reasons I listed in
  http://article.gmane.org/gmane.comp.version-control.monotone.devel/8287
are basically about user experience.)  So looking at how people use
branches, and how we can build interfaces that support useful mental
models, really is important before 1.0.

Besides, I don't personally have much useful to say about policy
branches right now anyway, so I might as well play with graph layout
algorithms while my hindbrain works on it :-).

Anyway, not trying to sledgehammer you for doubting or anything; hope
it doesn't come across that way.  The kind of reasoning that's driving
this work seem useful to put out in the open.

-- 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