Re: [Monotone-devel] Release time

[Timothy Brownawell]

On 05/27/2010 06:08 PM, Jack Lloyd wrote:
> On Fri, May 28, 2010 at 12:26:22AM +0200, Zbigniew Zag??rski wrote:
> > Hi,
> >
> > 2010/5/27 Jack Lloyd<address@hidden>
> > > I can think of a few things that might potentially happen that might
> > > be harder to pull off post-1.0:
> > >
> > > ??- s/netxx/asio/
> >
> > AFAIR, it's only implementation detail. Do we wan't to change netsync
> > protocol together with asio introduction ?
>
> I don't know. Probably netsync could be done via asio vs netxx in a
> totally compatible way, but I don't know for certain. It was more a
> suggestion for discussion than anything else.

We exercise total control over the bitstream, rather than using the 
library to packetize etc; the only thing we use it for is abstracting 
away sockets and select(). Changing libraries would only be an issue if 
asio would be a runtime dependency (I think it requires boost::system?) 
and we don't want to change those during a stable series (no idea if 
that's even an issue).

> > > ??- netsync over TLS
> >
> > It's a "pure new feature" that could be easy added over existing monotone
> > functionality.
> >
> > Am i missing something ?
>
> It would definitely depend on implementation. In OpenCM (opencm.org)
> what we did was use TLS with client auth using self-signed X.509
> certs, which seemed like a very elegant approach to me, and would
> obviate the current custom auth protocol.  This could be viably done
> in a forwards compatible way; upon upgrading to a mtn using TLS, just
> create new self-signed certs, and verify certs as usual using the key
> data. However it does seem to imply a flag day of some sort, which is
> bothersome. Though with some forethought and careful design the
> trouble could probably be minimized.

Netsync has version negotiation now, so this can be made compatible.

But, the version negotiation happens before any authentication and 
before the hmac is started, so someone could force a fallback to an 
older unencrypted (but still authenticated) version. This could be 
mitigated somewhat by requiring an --option to permit falling back to a 
pre-SSL netsync version.

> > > ??- policy branches
> > > ...
> >
> > Giving that lot of us consider monotone as stable and production
> > ready,  policy branches (+nuskool sync maybe) will a "revolution"
> > that fully justifies even "2.0" switch ... considering that we will decide to
> > lock 1.0.

I expect I'll have policy branches in a presentable state by the end of 
the year, or maybe early next year. So it will probably be mergeable by 
mid/late next year.

Is that a reasonable timeframe for a major version change, or are they 
supposed to last longer than that?

> Perhaps so. I personally consider monotone as both stable and
> production ready (as evidenced by the fact that I keep 99% of my
> important data, ranging from software to my website and app configs,
> in mtn). But with some flaws that I think are important to address,
> and I would just hate to see adopting 1.0 now cause them being
> addressed held back. (And yes, I know, obviously if I really cared
> about them I should spend more time writing patches for mtn to fix the
> problems that bother me).
>
> -Jack
>
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel


--
Timothy

Free public monotone hosting: http://mtn-host.prjek.net