users@glassfish.java.net

GlassFish Contributions (was: GLASSFISH IS LAME)

From: Eduardo Pelegri-Llopart <pelegri_at_sun.com>
Date: Thu, 23 Jul 2009 11:20:16 -0700

Bit by bit we are cleaning things up and making it easier to contribute.

Currently most (non-corporate) contributions to GlassFish happen in the
subprojects, places like Grizzly, Jersey, Mojarra/JSF, Metro, etc. Over
time I expect us to have more of these, and the modularity in v3 (once
we clean up all the kinks) will also help.

That said, note that just having a bug fix ready does not necessarily
mean it can be incorporated into the main release right away. It is an
intrinsic tradeoff from "Public releases are fully tested and supported"
and "Getting releases out in scheduled dates".

...

I'd also like to second Jerome and encourage participation on the
engineering meetings. We try to be very transparent and public in all
decisions, but the more individual contributors there, the easier it is
to do a good job.

        - eduard/o


Markus Karg wrote:
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>