monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Release time


From: Jack Lloyd
Subject: Re: [Monotone-devel] Release time
Date: Thu, 27 May 2010 19:08:03 -0400
User-agent: Mutt/1.5.20 (2009-06-14)

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.

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

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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]