Screw "the future".

[Holger Hoffstätte <ho...@wizards.de>]

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.

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

Re: Screw "the future".

[Niclas Hedhman <ni...@hedhman.org>]

On Fri, Dec 12, 2008 at 1:00 AM, Holger Hoffstätte <ho...@wizards.de> wrote:

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

I don't think we have social problem. I just think that the
'committers' are fairly pleased with what exists and don't want to
rock the boat. After all, there are indeed many important
projects/products out there successfully depending on this technology.
And I totally respect that. I don't want to toss away the 2.1 trunk,
it is will be maintained even if I had free hands to do what I want.

But I think River can rise from the ashes of Jini, especially today
when we see "Clouds" and funky computers like Azul Systems, where
these ideas will come of age. Problem is, Jini has played its card and
lost the developer battle. So, IMHO, River will maintain Jini 2.1
as-is, learn from this and resurrect Apache River Distributed
Computing, without bazooning out that this is the next Jini.

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

There are more than one way to do a 'big rewrite'... One includes not
re-writing the actual code, but looking at how it is structured,
replacing smaller bits, adding some sweets and repackaging it in a new
shiny box or perhaps different boxes for the ladies in the room. I
totally agree that there is no point in re-writing the codebase.
Another thing is that one should look at aligning oneself with the
rest of the market place and create attention...


Cheers
Niclas

Re: Screw "the future".

[Holger Hoffstätte <ho...@wizards.de>]

Robert Burrell Donkin wrote:
>> I will not mention the consequences of a centralized scm very
>> intentionally. (:
> 
> blaming the version control system is easy but misguilded

"very intentionally" meant it would have been anything but misguided. I
hope you're not suggesting that the implications of a dev process or tool
choice are negligible.

> the apache development model is canonical, which determines the choice
> of version control system.

..and that is exactly the fallacy that I did not want to expand on. And
still don't want to, either (at least not here).

> this choice of model is both philosophical
> and practical.

I never disputed that, either. :)

> the apache software license is not reciprical and so
> this means that contributions can only be accepted with oversight and
> due legal process. only one version of the code will be approved for
> release by the PMC as a canonically numbered version.

All that makes sense, and for good reasons. It does not in any way
contradict my observations.

regards
Holger

PS: for those wondering about the potentially offensive subject line -
there was supposed to be a "let's fix the present" that went missing.
sorry about that.

Test

[Michael McGrady <mm...@topiatechnology.com>]

test

Re: Screw "the future".

[Robert Burrell Donkin <ro...@gmail.com>]

On Thu, Dec 11, 2008 at 5:00 PM, Holger Hoffstätte <ho...@wizards.de> 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.
>
> 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.

successful forking of apache licensed projects usually require a
sufficient community and is much less common than with GPL'd code
bases. external forks have to pay the price for the legal overhead
associated with an AL'd project. internal forks have worked quite
successfully in the past especially when codenames have been used.

> I will not mention the consequences of a centralized scm very
> intentionally. (:

blaming the version control system is easy but misguilded

the apache development model is canonical, which determines the choice
of version control system. this choice of model is both philosophical
and practical. the apache software license is not reciprical and so
this means that contributions can only be accepted with oversight and
due legal process. only one version of the code will be approved for
release by the PMC as a canonically numbered version.

- robert

Re: Screw "the future".

[Wade Chandler <hw...@yahoo.com>]

----- Original Message ----

> From: Robert Burrell Donkin <ro...@gmail.com>
> To: river-dev@incubator.apache.org
> Sent: Monday, December 22, 2008 3:53:46 PM
> Subject: Re: Screw "the future".
> 
> On Sat, Dec 20, 2008 at 10:41 AM, Dan Creswell wrote:
> 
> 
> 
> > 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).
> 
> i've been reading this list for some time now and i would like to take
> this opportunity to step in now (before positions get too entrenched
> and anyone does anything hasty)
> 
> i've observed many symptoms that arise from the problem of a mature,
> high quality codebase. it's hard to develop a bigger and deeper
> community with this kind of code base. reviewing patches contributed
> is time consuming, and too many correct solutions require too much
> investment. in the long run, though, new live and ideas are almost
> always needed but it's hard to know which ones will really benefit the
> codebase until they have been explored reasonably fully in code.
> 
> i doubt that a binary fork is the answer. apache does not use a
> benevolent maintainer model but a collegiate one. there is no need for
> any minority to step aside in favour of any other.
> 
> i suggest allowing a variety of internal forks. providing that those
> developers who want to push river forward in different directions
> agree to work in outside trunk, it should be possible both to work on
> perfecting the current codebase and on experimenting in new
> directions. if this sounds anything like an acceptable solution to the
> current committers, then i can offer some suggest about ways and means
> to do this which have worked ok in the past here at apache.
> 

This is indeed the way NB works:
http://hg.netbeans.org/

Plenty of branches which are not necessarily going to be ported back into the trunk/main, but are created and worked in as things need to be explored. Without exploration, the ability to do so, and the flexibility to try new things and get folks to at least look at it what kind of a community would it be? The source control system can help here as with Hg one can share their repository/clone and their modifications more easily without it having to be hosted on a particular server, but that too can cause other headaches such as locating branches/forks, user control, etc. Anyways, the main point is not everything has to be worked on in a single branch, and not every branch has to make its way back to the trunk. But, ideas and code and communicating about them are essentially the only things these type communities have outside of users and requirements, and that is part of what makes them fun.

Wade



 ==================
Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org

Re: Screw "the future".

[Michael McGrady <mm...@topiatechnology.com>]

+1 from a non-committer.

  Mike


On Dec 22, 2008, at 12:53 PM, Robert Burrell Donkin wrote:
>
> i suggest allowing a variety of internal forks. providing that those
> developers who want to push river forward in different directions
> agree to work in outside trunk, it should be possible both to work on
> perfecting the current codebase and on experimenting in new
> directions. if this sounds anything like an acceptable solution to the
> current committers, then i can offer some suggest about ways and means
> to do this which have worked ok in the past here at apache.
>
> - robert

Re: Screw "the future".

[Robert Burrell Donkin <ro...@gmail.com>]

On Sat, Dec 20, 2008 at 10:41 AM, Dan Creswell <da...@dcrdev.demon.co.uk> wrote:

<snip>

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

i've been reading this list for some time now and i would like to take
this opportunity to step in now (before positions get too entrenched
and anyone does anything hasty)

i've observed many symptoms that arise from the problem of a mature,
high quality codebase. it's hard to develop a bigger and deeper
community with this kind of code base. reviewing patches contributed
is time consuming, and too many correct solutions require too much
investment. in the long run, though, new live and ideas are almost
always needed but it's hard to know which ones will really benefit the
codebase until they have been explored reasonably fully in code.

i doubt that a binary fork is the answer. apache does not use a
benevolent maintainer model but a collegiate one. there is no need for
any minority to step aside in favour of any other.

i suggest allowing a variety of internal forks. providing that those
developers who want to push river forward in different directions
agree to work in outside trunk, it should be possible both to work on
perfecting the current codebase and on experimenting in new
directions. if this sounds anything like an acceptable solution to the
current committers, then i can offer some suggest about ways and means
to do this which have worked ok in the past here at apache.

- robert

Re: Screw "the future".

[Dan Creswell <da...@dcrdev.demon.co.uk>]

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
>