dev@glassfish.java.net

Re: *early* draft of Principles of Project GlassFish...

From: Craig McClanahan <Craig.McClanahan_at_Sun.COM>
Date: Tue, 22 Aug 2006 23:06:29 -0700

Eduardo Pelegri-Llopart wrote:
> I have written down an early draft of Principles for Project
> GlassFish. See:
>
> http://blogs.sun.com/roller/page/theaquarium?entry=draft_of_principles_for_project
>
>
> Comments via comments on blog, comments on Wiki page, or in this mail
> thread.
>
> - eduard/o
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
Eduardo,

Lots of this document is indeed goodness and apple pie. A couple of
areas made me pause for thought:

* The "participatory" section (and the related comments in other sections)
  doesn't really help set the expectations of someone who might actually
want
  to contribute something (from a patch to a new module). Is anyone
going to
  pay attention to me? What does it take to get committer access? Even
if I
  have committer access, are there limits on what I can change? Some of
this
  might really belong in a governance document instead of a goals document,
  but the last thing we want is people trying to get involved (perhaps
with starry
  eyed optimism, perhaps without having read anything), but then get
disillusioned
  due to (perceived or actual) lack of response by the process. Can we
do anything
  to set realistic expectations (at a high level) here?

* The "partner centered" bullet is going to be a mystery to an individual
  open source developer who wants to get involved. Can we be a little more
  explicit about what that means?

* The bullet about "Provides Java EE Reference Implementation" seems out of
  place in the section it's under. It's almost like this is secret code
words for
  "you don't really have the freedoms you would have in a typical open
source
  project to change anything you like." If that's the reality, then we
should just
  say so (by documenting a guiding principle that we will faithfully
implement the
  set of JCP standards we aspire to support, including passing the TCK
tests).
  But that whole area seems like a separate main bullet point, unless we
want to
  engage in discussions about whether the JCP is an "open standards" process
  or not. Such discussions are interesting and relevant, but they
shouldn't be
  distracting the Glassfish project from what we are trying to accomplish.

Craig