river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Screw "the future".
Date Mon, 22 Dec 2008 21:47:45 GMT
----- Original Message ----

> From: Robert Burrell Donkin <robertburrelldonkin@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:

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 Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team
Member, and NetBeans Board Member

View raw message