Jon Stevens wrote:
> 4.2.1: Define "minimized". In other words, something that seems minimal to
> one may not seem minimal to another.
This is merely meant to reinforce the original intent that the packages
be as independent as possible, and not evolve (or devolve) into a
framework. Since these are guidelines, rather than rules, I believe we
will have to trust our future selves to do the Right Thing(tm).
> 4.2.2: I think that "should" should be changed to "must".
+1
> 4.3: Define a number on the amount of committers.
This provision is meant as a roster, or a simple "whoWeAre". The initial
committers would be set forth in the package proposal. Based on the
scope of the package, the committers voting on the proposal should
decide if there is sufficient support or not.
The "core committers" at #16 are meant to ensure that all packages have
coverage, and could lobby for other committers to step up if a package
were orphaned. Of course, since the packages are usually being created
by Jakarta committers for use in Jakarta products, hopefully this won't
often occur. In the discussions, other pointed out that if a package is
orphaned it is either rock stable or obsolete.
> 5: It should be a "must". Also, this whole point is *WAY* to broad. What is
> "standard"? I see at the bottom there is a Resource section, but I don't
> think that covers it well enough.
-1. I'm reluctant to say more until we have developed a working example
or two. Since these are subproject guidelines, the committers can
upgrade these guidelines later if appropriate. Again, this is meant to
reinforce the original intent, and to help keep things on track.
> 6: I think that "should" should be changed to "must".
=0. I'm just reluctant to force more than is absolutely necessary.
> 7: Should provide an interface or implement a Sun defined interface.
+1
> 9: what is the definition of "preferred"? Is that a "should" or "must"?
< ... />
> Additional: the issues surrounding logging and pluggable logging
What Peter said regarding this point.
> Resources:
> May I suggest that the Java coding documentation be amended to require
> *NOT* having tabs in the files. The reason it simple: tabs make it
> nearly impossible to read the CVS commit logs because emails don't
> format properly with tabs.
+1
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
