harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: communities shouldn't be partitioned
Date Fri, 12 May 2006 11:55:28 GMT
Leo,

We partitioned Harmony contributors a long time ago (based on prior
access as declared in the ACQ), so while you state it as:

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

in fact there are people who only *can* contribute to a part of the
Harmony codebase, and some of those will be fine people that become
committers (right George ;-) ?) and we should welcome them.

Beyond such restrictions, I agree with your comment that Harmony
committers must keep a watching brief over the entire project.

The size of this project is set to grow considerably if/when the DRLVM
is accepted and we tackle new areas of the class library etc.  The
number of committers has to grow too and I expect there will be a
natural grouping of parties around the VM, JIT, UI, performance, etc.  I
doubt any one person will be in a position to scrutinize equally all
changes in any part of the code JCHEVM, BootVM, classlib, DRLVM, JIT,
GC, etc.

So reading your mail carefully -- I agree.  I'm comfortable that we are
not prematurely splitting Harmony beyond the lines already drawn in the
project, but I support the work to ensure that the lines remain distinct
since we can predict that such specialization is very likely to occur.

Regards,
Tim

Leo Simons wrote:
> 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
> last):
> 
> 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.
> 
> cheers!
> 
> LSD
> 
> ---------------------------------------------------------------------
> 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
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

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


Mime
View raw message