Oh! I forgot to add... I think that the reverse should also apply. I do not think that it would be OK for current Harmony commiters to simply go and change the SableVM code without discussing it on this list first. Their right to commit obvious little patches and improvements within the sablevm code, without prior discussion on this list, should be earned too.
It's not only a question of fairness; it is a technical one. Even if some of the SableVM code might look simple, there are often deeper principles behind the code. It is easy to transgress important correctness rules without noticing it. The C language offers no protection against it. [Rules about stopping/resuming java in VMI code, etc.] JCHEVM simplified many problems by selecting a non-moving collector. SableVM has not only a moving collector, but also moving Java frame stacks, etc. Lots of tricky (yet nice) stuff. :-) Etienne > So, how about the following: We go with some hybrid of your options #2 > and #3. The number of "automatic commiters" is limited to two > developers: Greg and me. To commit anything outside the SableVM code, > Greg and me must first discuss it on this list, and get the consent of > Harmony developers. The right to commit obvious little patches and > improvements outside the sablevm code, without prior discussion on this > list, must be earned. -- Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
signature.asc
Description: OpenPGP digital signature
