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!
I fully resonate with Leo on this topic. Before suggesting a solution, state the problem: you might find the distributed and open problem solving approach to yield insights that you didn't have when you came up with your own solution... and also a clearer way to understand how different problems are related. It's a general approach, really, but it works best in places where the collective IQ is orders of magnitude greater than individual ones... especially when the individual IQs are way above the human average. -- Stefano. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
