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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
