Jerome,
still you did not convince me (and remember, I *am* / *was* a
contributor to Java EE 6 / 5 in projects).
The point is that GlassFish's internal structures are completely Sun /
Oracle inventions, so nobody outside of this companies has the time and
knowledge to understand it. If you really want to get volunteers in the
boat (remember, we are no students, we all are long-experienced software
architects), you must get the code to a style that allows externals to
work on small components which can be overseen in the spare time. I
tried with EclipseLink. It is nearly impossible, since it is Spaghetti
Code in some areas.
Also, people not only want to do the "dirty work" like doing the hacking
while others do the decisions. They want to participiate in the
decisions. Remember, we do not talk about specification decisions
(everybody can become part of JCP), we talk about *implementation*
decision. Why? Because this thread started about bugs, and bugs are not
decided by JCP, obviously.
So in theory you are right, everybody can participate in JCP. But in
reality nobody cares for JCP, they all care for the implementation,
since this is what users see and feel later. And THERE nobody outside of
Sun / Oracle can officially participate. Or did I miss a link where I
can add myself to the EJB 3.1 Client Container team to actively
participate in the decisions that where leading to the hangs that I
still experience...?
Regards
Markus
> The processes to define what goes in glassfish is much more open than
> what you seem to think. First of all, even Sun engineers don't have
> that much to say in what goes into glassfish because it's mostly
> driven by specifications. Specifications are driven within the JCP and
> are open to external participants so one good way of driving features
> into Glassfish and others appservers is actually to participate to the
> JCP process. Above the Java EE specifications, we have also released
> all the product specifications by feature and that's also an
> opportunity to add or criticize.
>
> On top of that, we have had a lot of committers willing to participate
> to the GlassFish project itself. I have personally tried to involve
> some of these external committers to some task (yes they have to start
> small so we gain confidence) but in general, the GlassFish project
> being so big, the source code is intimidating, or the people just end
> up not having the time, most of them don't follow up. We do have some
> who participates daily and I don't think we ever kept them in the
> dark. All meetings are open for anyone to join at least by phone.
>
> At the end, I don't remember shutting out anyone willing to
> participate (granted his level of participation was useful) but the
> reality is that we cannot expect external folks to be able to spend
> considerable amount of their personal time on the project which would
> be necessary to not introduce more risks to a schedule.
>
> For such a big project, the overwhelming size of the code, the time
> involved in understanding enough of GF is probably the biggest barrier
> to participation but it's certainly not a conscious decision from Sun
> to hide anything.
>
> >
> > Regards
> > Markus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net