Re: [Monotone-devel] [RFC] M.T. phone home

[Nathaniel Smith]

On Thu, Jun 08, 2006 at 11:00:47AM +0200, Marcel van der Boom wrote:
> Would it also be possible to see if people follow the 'intended  
> philosophy'? I mean, on situations where monotone barfs something  
> about tmp directories, orphaned nodes, rename conflicts and what have  
> you, do they bail out and start over or do they 'use the force' to  
> get back on track?

Umm, I dunno... depends on whether we can write code to detect whether
they are using the force or not.

I guess if we saw a lot of "merge with exotic conflicts" followed by
calls to "db init" that would be a clue...

However, what I really want to know now is how to make this kind of
feature Non-Evil and ideally even Non-Controversial; we have plenty
of time to work out exact details of how we analyze the data etc. 

> The above reminds me of the openlogging 'feature' that bitkeeper had/ 
> has. Apart from what you described above, the main usefulness (to me)  
> was to have a 'unified activity' view of the repositories. If people  
> were working on stuff locally, experimenting, but not pushing yet, it  
> showed me that and I was able to contact those people saying "hey, i  
> see you're working on something which is also done by those two guys  
> there, perhaps you want to set up some form of communication"
> 
> In general, the sending of the 'activity log' has a balance which  
> tips over to the 'monotone hackers' on short term, users presumably  
> benefit from the conclusions drawn from those logs by having a better  
> monotone longer term.
> 
> If there would be a way, perhaps by not only sending the activity log  
> to a 'monotone place', but also allowing users to set up their own  
> 'project home'. Having information about your project's activity  
> without having to go through the trouble to teach everyone how to  
> 'serve' monotone (so revs can be exchanged directly) can be very useful.

I think this is pretty orthogonal, since the emphasis of the system
I'm talking about would be exactly to make it _hard_ (ideally,
impossible) for anyone to figure out what was actually being worked on
from just the data it gathered :-).

It's also not clear to me how this would work; if people aren't
pushing their code, why would they be pushing their logging info?

(With BK, of course, the difference between pushing code and pushing
logging info is that the latter always works, while the former
involves merging branches that perhaps should not be merged.  But
monotone works hard to make pushing code orthogonal to project-level
decisions like that, so pushing code and pushing logging are pretty
much the same.)

-- Nathaniel

-- 
Damn the Solar System.  Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better one myself.
  -- Lord Jeffrey