river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <...@dcrdev.demon.co.uk>
Subject Re: Screw "the future".
Date Sat, 20 Dec 2008 10:41:08 GMT
Holger Hoffstätte wrote:
> Jools wrote:
>> So many times I see "I've made a local change to allow..... blah blah
>> blah", so why wasn't it easy to get that change into the code base in
>> the first place ?
> 
> Because the Apache committer model, combined with the chosen
> patch-and-review process and the set of existing River committers, are
> apparently not compatible with each other. I say this simply as an
> observer of the results, without trying to imply too much.
> 
> Since lenghty discussions at Apache (elsewhere) have made it clear that
> the former is unlikely to change, that would leave the latter as, erm,
> attack vector.
> 
> Speaking as someone who used to successfully fix teams and dev processes,
> I can assert say that the intended dynamics by the meritocratic model only
> work under certain social circumstances. These do not seem to be met - in
> other words, for whatever reasons the committers are either not committed
> or committing.
> 

The committers had an early discussion around next steps - they
concluded, roughly speaking, that they'd do some patching up and
cleaning and get the release process etc bed'ed in.

I pushed to get a vision in place, but most seemingly weren't
interested.  I personally felt the code was stable enough that the
longer-term vision was more important and stood back on the basis I
apparently wasn't in the majority.  Those that did buy the stability
work had time also whilst I was making a career change which meant I
didn't have time to dedicate.

I now have time to dedicate but as yet haven't seen much that I'd
dedicate time to (other than fixing the setup problems).

We've now had another go at a vision and this time run into conflict
around local vs remote, apparent architectural issues, setup problems
and some other bits and pieces.

If Niclas is representative of the majority I'd be prepared to step down
and let you all have at it.  Note that I don't agree philosophically (on
the remote vs local stuff) with what you're doing but as the minority
will happily step back, take a copy of the source code as it is now and
fork (because I believe the philosophical difference is too big to do
otherwise).

> That being said, I agree that forking would be counterproductive at this
> point, if only because many small incremental improvements can be fixed
> without falling into second-system-syndrome and the "big rewrite/fix
> everything" trap.
> 
> I will not mention the consequences of a centralized scm very
> intentionally. (:
> 
> Holger
> 


Mime
View raw message