Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
Date: Wed, 4 Jun 2003 22:46:31 -0400
Subject: Re: Empowering the Developers
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Peter Royal <proyal@apache.org>
To: "Avalon Developers List" <dev@avalon.apache.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: <200306051019.25288.niclas@hedhman.org>
Message-Id: <E9E9A574-96FF-11D7-A95F-000393B61B56@apache.org>

On Thursday, June 5, 2003, at 02:19  PM, Niclas Hedhman wrote:
> Amen. Especially, since the life of a non-committer is pretty hard, 
> i.e.
> making small changes are hard to maintain in isolation, annoying to 
> submit a
> patch/proposal, getting the patch applied by a committer, tracking 
> when that
> patch is applied...
> And doing a larger piece is even worse, let's say a refactoring of a 
> couple of
> implementation classes, since the patch may be "invalid" by the time a
> committer try to apply it.
>
> Peter D, not until you allow anyone with strong interest to
> maintain/patch/enhance avalon codebase can you have this fairly 
> arrogant
> attitude between "developers" and "users" (who in Avalon's case is 
> fairly
> advanced developers as well).

that's the paradox :)
you get commit access by bombardment with patches, but that takes 
work.. i don't think pete d is arrogant, rather brutally honest. 
although not necessarily stated in the most elegant manner :)

i consider anyone that contributes energy back into a project as a 
developer. so anyone that contributes back, be it via discussion or 
code, committer or not, is a developer. real "users" to me are ones 
that never contribute anything back, only using releases, reading 
documentation, and occasionally asking questions. they're just 
consuming the energy of the project. nothing wrong with that, but 
developer energy is a must to keep things sustainable.


that's the reason i love good, easy to use issue tracking systems, it 
makes the "tracking when that patch is applied" piece much easier, 
which i find to be the largest pain.

for larger refactoring, a heads-up that you will be creating such a 
patch is usually enough to give you a safe period with which to not 
have the code underneath changed so the patch is invalid.

(and i'll assume that most interested parties are operating out of an 
anonymous cvs checkout of the project anyways, its the only sane way to 
work. but that also explains abysmal release processes)
-pete


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org