harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject communities shouldn't be partitioned (was: Re: Supporting working on a single module?)
Date Fri, 12 May 2006 09:34:09 GMT
Hi All!

I've been wanting to respond here for a while, but its kinda hard since
a lot of things seem to be getting somewhat "mixed up". Eg

 * the current build system is not performant enough when doing
   incremental rebuilds

 * the development process doesn't have enough rules or incentives
   in place to promote decoupling between modules

 * the codebase is so large that an SVN checkout of "everything"
   (takes too long|uses too much bandwidth|breaks down|...)

 * there are people who want to only ever work on a small part of
   the codebase

and others, or at least things along those lines. I think it would be
productive to seperate them out a little further and try and tackle
some of these as seperate issues in seperate threads. Eg "is it ok if
we try and get rid of recursive make" is a much easier topic, and
seemingly gets you a little closer to whatever the overall goal presented
in this thread is (something I haven't quite been able to understand yet).

With that in mind, I'm going to tackle only the first bit (which I listed

On Tue, May 09, 2006 at 03:07:03PM +0100, Mark Hindess wrote:
> As the Harmony Classlib grows, I think that being able to work on a
> single module (or some subset of the modules) will become the typical
> way of working for many (perhaps even most) contributors.  So I think
> we need a plan to support this. 
> What do you think?

I think it is very important that our committers keep afoot of what is
happening all around the codebase, and don't focus on maintaining just
a single module, and such a plan should make sure that this is encouraged
and expected of everyone.

If that is not a mode of operation that can scale, we need to thoroughly
reorganize the project organisation and "modus operandi". Experience
shows that such a reorganisation takes many months if not years (Re:
jakarta), is best done incrementally as the need arises, and only with a
lot of caution.

I think this kind of reorganisation should not even be attempted for an
incubating project. We don't have the neccessary experience or critical
mass to make it work (yet). So we fall back to "be aware of roughly 
everything happening throughout the codebase". You are responsible and
will remain responsible for ensure that your patch or commit does not
introduce a regression anywhere. This often implies running the
appropriate amount of regression/integration/etc tests and "make world"
style builds (oh, and paying careful attention to the outputs of tools
like gump :-)).

I chose the word committer carefully. We might very well have quite a
few contributors contributing to only one small part of the project (like,
I dunno, java.beans) who aren't all that interested in any of the other
bits, but I feel we need to make sure that this kind of "use case" does
not in any way impact the "main one" (where we're all in this together
and are all contributing to this bigger goal of a full jdk).

So sure, optimize away on build systems and development tools and code
organisation and try and implement ways that lots of different people can
contribute in the way they want to, but make very very sure that such a
kind of "partitioning" applies only to the source code (and resultant
object code and stuff of course) and not to the people, the mailing lists
or the way in which people work together.

Now, I realize you might not have been even close to wanting to imply
something that conflicts any of the above (I hope so!); I just wanted to
highlight the "community feeling" "use case" as in many ways being the
most important one.



Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message