geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <>
Subject Re: Request change to RTC Process
Date Mon, 19 Jun 2006 23:28:17 GMT
I'm not sure Ken's intent was to introduce a new concept as much as he was pointing out a side

benefit.  My understanding was that RTC was enforce to improve community collaboration and

communication.  Clearly its not working very well based on the comments in this thread.  Seems
to be 
going the opposite way.

Clearly the opinion of some on the thread is they trust each other and communication has already

been fine so this is just slowing them down?  Is that the summary?  I'd have to disagree that
have been fine although I'll concede that perhaps some changes to RTC may be warranted.

I'm sitting in an airport right now so I don't have time to do this but it might be nice if
can compile some statistics on what has actually transpired and then we can discuss why this
working and then make some recommendations as to how to move forward rather than the current

dialogue which doesn't seem to be improving collaboration and communication but is actually
polarization (which I think we're trying to avoid).

Hiram Chirino wrote:
> On 6/17/06, Rodent of Unusual Size <> wrote:
>> RTC means tested quality, not assumed quality.  If you
>> can't find people to test the quality of something, it
>> doesn't go in because the quality isn't assured.
> I'm not sure where 'quality' requirement is coming from.  I don't
> think it's ever been discussed on the list.  For example, I don't
> remember a discussion of should we focus on stabilizing and in effect
> slowing down the development of Geronimo.  Or should it focus on
> implementing the J2EE features that it's missing as quickly as
> possible?  I can see how IBM would prefer the 1st option since it
> would allow it's chimerical offerings to stay differentiated from
> Geronimo. But I don't think the rest of this community would agree.

I'm having trouble understanding the above paragraph and Dain's comments in another e-mail.
proposed that we take 1.1.1 to stabilize it because there are a number of quality issues in
that make it undesireable in a production enviroment.  NPEs abound and we have usability problems.

Personally I think these need to be addressed to improve the adoption rate of Geronimo.  I'm
aware of a lot of developers or administrators that accept a server that is 90% reliable (my
made up 
number).  If you disagree that fixing these are a waste of time then please speak up.  I have
things to do then.

I'm also having difficulty understanding the chimerical comment.  I can only assume that you
that WAS CE is some mythical and unachievable goal?  Here is where I'm drawing my inference

Here is a quote from the above:

1. Merely imaginary; produced by or as if by a wildly fanciful imagination; fantastic; improbable

If WAS CE is mythical then I'm not sure what hope there is for Geronimo because it is the
basis for 
WAS CE.  If CE can't succeed then I'd say Geronimo poisoned the apple.

Can you please clarify your comments Hiram because they aren't making sense to me.  I'm sure
don't mean the above.

>> >  - Eliminates trust.  I know say, David J has a lot of experience with
>> > say, connectors, and if he puts a patch in that area, I think I can
>> > read his summary and trust that he's implemented it sensibly.  But now
>> > that doesn't count, I have to review it line by line?  I think it
>> > should be up to me which patches I trust and which patches want to
>> > review in detail.
>> Considering the problems concerning trust that are already
>> extant, I think the first sentence as a conclusion is bogus.
>> And once again you want to *assume* quality rather than *assure*
>> it.  That's how CTR works.  RTC works to *assure* it.
> I trust a bunch of the folks that work here and while I could review
> patches, unless you are working with that code ALL the time, there
> could be unexpected side-effects that only folks working on it all the
> time could catch.  So I would rather than assume I know what I'm
> doing, I'd delegate to folks who specialize in that area of Geronimo.

By way of example, if its connector or Tx code I'd trust Jencks.  Perhaps the problem is that

Geronimo has not attracted enough people to have more than one person interested in a specific
  I would say this is unfortunate but I agree with your trust comment in light of individual

>> >  - Favors full-time open source developers over free-time
>> > contributors.  I don't have enough time to work on the work *I* want
>> > to do in my spare time, much less get a clean tree to apply, test, and
>> > review everyone else's patches
>> I don't consider this valid, either.  If you have the
>> time to be a committer, you have the time to be part of
>> the community and collaborate with your peers on the
>> project.  One thing about RTC is that it tends to promote
>> interaction, since people are dependent on each other and
>> the occasional quid pro quo -- unlike the everyone haring
>> off in his own direction with no-one else watching that
>> can occur (and has occurred) under CTR.
> Well, I think I have my plate full just implementing that patches.  I
> think every one's plate if full too.  So either we are slowing down
> everything by 3x or we are assuming that every one's bandwidth was 1/4
> full (or something like that).  It seems to me that things have slowed
> down by 3x.  BTW who are the full time developers on Geronimo?  Cause
> it seems to me that If I want to get my patches in I better start
> helping them out so that they can return the favor.

I think your last comment is the point in terms of working together.  Your comments are valid
code quality would slip in other areas if we're all spread so thin that we can't get anything
  We are interested in quality code, right ?

>> No-one says you have to test *anyone* else's patches.  Unless,
>> of course, you hope they'll test *yours*, which is where
>> the collaboration-for-the-project aspect comes in.  So if
>> you don't find time to test someone else's code, regardless
>> of for whom he may work, don't expect him to spend a lot
>> of time testing *yours*.
>> >  - Favors bug fixes over innovation.  Anything that's characterized as
>> > a bug fix gets a free pass.
>> Quality, remember?  Not bells or features.
> I would agree we need quality in the 1.0.x and 1.1.x development
> branches.  I don't think we need to stress quality in the 1.x
> branches.

Perhaps this is a point that needs to be clarified with the community.  I've seen other posts
talk about stable and unstable branches.  I think this makes sense in the short term and perhaps
the long term if there are people that are interested in shoring up Geronimo.  Hopefully the
writing the prototypes would be good enough to help fix the other branches as well :)

>> >  - Encourages "cliques".  Who am I going to ask to give me a quick +1?
>> Rubbish.  'Cliques' is exactly what the previous environment
>> supported.  No such thing as a 'quick +1,' unless the patch
>> has been tested quickly -- and by three people.  Anyone who
>> gives a quick +1 as lip-service under RTC is in trouble.
> Right.. but, you still need to entice 3 other people to do work for
> you.. Unless I 'm giving them a pay check, this is sometimes hard to
> do.  I think that 'cliques' of a sort will form.  In the heavy
> lifter's sub-consciousness they will soon start to think "I'll review
> X's patch because I'm in debt to him since he reviewed my patch.  If I
> don't keep working on his patches, perhaps he will stop working on
> mine."  Also, I would think that folk who work for the same employer
> will be more likely to review each others patches before they review
> patches for folks they don't know.

I think we already have cliques of people that are accustomed to working together.  This isn't
problem if they are not exclusionary.  Otherwise it would be hard to grow the project.  Perhaps
is Ken's point and he is looking for evidence that this is working.  My guess is that if people
to work alone we'll see more sandbox activity and side branches where activity occurs rather
trunk.  If thats the case then I think Ken's concerns are validated to an extent.

>> > Now, you can argue in favor of this for a maintenance / bug-fix
>> > release like 1.1.1, where the main goal is to improve quality and
>> > extra eyes on every line may help avoid bugs.  But it's a significant
>> > obstacle for a feature release like 1.2.
>> Only if some specific date schedule is a factor.  And if it is,
>> I ask again: why?  Or if the 'features' aren't sufficiently
>> popular among the developers -- in which case why should they
>> be included?
> You bring up 2 issues.  J2EE requires you to implement a ton of non
> popular features.  They are features no one really uses!  And they are
> hard to implement.  So, yes we need to develop un-popular features
> because they are mandated by J2EE (Just think CORBA).
> The date thing.. Isn't the aim of Geronimo to be the best open source
> Application Server?  Well, we are not right now.  I don't want to work
> on a project that is content with not being used.  "Lets do all this
> work and put it on the shelf."  It's cute, but it falls so short of
> everything else that is available.  And date has alot to do with it.
> There is no point in implementing a feature that has become legacy
> technology.

Yup, EJBs are a good example as well as J2EE WebServices.  Perhaps then Geronimo should decide
J2EE isn't its goal and jettison those features and not care about CTS.  I think that would
unfortunate as we'd lose the credibility of having certification but it sounds like people
rather be developing non-J2EE services and features.

> The success of the HTTPD server is because it got such huge adaptation
> in the market.  Once we get that kind of adaptation, I think we can
> all start to breath easier and start to thing about quality and not
> quantity.
>> > Additionally, it doesn't
>> > help the stated goal of improving communication.
>> I disagree here, as well.  I think it has already done a
>> tremendous job of improving communication.
>> > If everyone wants to
>> > see what I'm doing, and I post it to a Jira and announce it, they can
>> > see.  If they want to review in detail, they can.  If they can review
>> > the description and perhaps give it a cursory glance and give it a +1,
>> > that's achieved the goal of making sure they're aware of things going
>> > on in the project.
>> You're replacing the 'must be reviewed' aspect of RTC -- which
>> is the major point -- with 'reviewed if people feel like it
>> and remember to.'
>> RTC means that you can't unilaterally and arbitrarily do
>> things *without* discussion.  Like, say, setting up a
>> non-project-sponsored .com site and pointing project code at
>> it without discussion.
>> > If you say they can't +1 it without an exhaustive
>> > review and test, that doesn't add to the quality or quantity of
>> > communication.  It only adds obstacles to delivering the features
>> > desired for the 1.2 release.
>> I regard the first sentence as as a completely baseless assertion.
>> For the second.. Again, only if time is a factor.  Or if changes
>> are too uninteresting to be able to get three people to even look
>> at them.
>> - --
>> #ken    P-|}
>> Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
>> Author, developer, opinionist      http://Apache-Server.Com/
>> "Millennium hand and shrimp!"
>> Version: GnuPG v1.2.4 (MingW32)
>> Comment: Using GnuPG with Mozilla -
>> X7cnZsvTGmQ4uZW7GiCjjkU2E0H0gGMIRUHFCuV8lul85DectAxE3+4M6pYPAG8v
>> wzg8OOYUl4Wmv6s31M1VDBruCseGLh01c+ilYl2G61mM+c+Ppt3dduD/VCqQDeao
>> 38KzZSDD1WM=
>> =M+w0
>> -----END PGP SIGNATURE-----

View raw message