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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
