geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <>
Subject Re: Request change to RTC Process
Date Sat, 17 Jun 2006 18:18:26 GMT
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.

> >  - 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.

> >  - 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.

> 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

> >  - 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.

> > 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

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

> > 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



View raw message