Hi Tim, Lemme join to Mikhail's words: very good! Thank you! I'm sure it will simplify the contribution process. Of course, we have committers who control the process, no doubts; however for me (and I think not for me only) it is much simplier to have the guideline of what structure is expected.
Could we call *anything_alse* somehow :-)? Personally I would prefer *external* as opposite to *internal*, but I expect nobody will agree. Let's me also support Mikhail in his comments: On 2/13/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > Looks very good! > > I have two comments/questions. > > 1. I thought we agreed that *some* tests should be in the same package as > implementations. How this fits together with a special package name for tests? Yeah, looks like it will cause visibility problems, won't it? > > > 2. Does not it sound too strict: "module developers who modify code that is > not > in an internal package must do so in a manner that ensures Java binary > compatibility"? How about "... should avoid breaking Java binary > compatibility > and must check that the change does not break other modules" Also agree. In general, binary compatibility should be supported, however it could be very complicated to eastablish proper interfaces from the beginning... Btw, is it right that the module contributor himself can decide what to put into functionality available for other modules? -- Anton Avtamonov, Intel Middleware Products Division
