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 Tue, 20 Jun 2006 01:29:52 GMT
On 6/19/06, Matt Hogstrom <> wrote:
> 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
> 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 things
> 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 someone
> can compile some statistics on what has actually transpired and then we can discuss why
this isn't
> working and then make some recommendations as to how to move forward rather than the
> 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 Geronimo
> that make it undesireable in a production enviroment.  NPEs abound and we have usability
> Personally I think these need to be addressed to improve the adoption rate of Geronimo.
 I'm not
> 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 other
> things to do then.

I think that's great! and I hope a 1.1.2 rolls out soon too and that
the 1.1 branch keeps stabilizing at a good pace.

> I'm also having difficulty understanding the chimerical comment.  I can only assume that
you mean
> 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 or
> unrealistic.
> 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 you
> don't mean the above.

lol.. that's why you can't trust spell checkers! replace chimerical
with commercial!  I was more referring to WAS compared to WASCE and it
staying highly differentiated because RTC could stifle geronimo's

> >
> >> >  - 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 area.
>   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 as
> code quality would slip in other areas if we're all spread so thin that we can't get
anything done.
>   We are interested in quality code, right ?

and mostly innovation.

> >> 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 that
> talk about stable and unstable branches.  I think this makes sense in the short term
and perhaps in
> the long term if there are people that are interested in shoring up Geronimo.  Hopefully
the people
> writing the prototypes would be good enough to help fix the other branches as well :)

Yeah. I guess we should start throwing up new threads for this.

> >> >  - 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 a
> problem if they are not exclusionary.  Otherwise it would be hard to grow the project.
 Perhaps this


> is Ken's point and he is looking for evidence that this is working.  My guess is that
if people want
> to work alone we'll see more sandbox activity and side branches where activity occurs
rather than
> trunk.  If thats the case then I think Ken's concerns are validated to an extent.

Perhaps.. I could see folks working on a branch/sandbox to validate
ideas before wasting folks time reviewing things that eventually need
to be rolled back.

> >> > 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 that
> J2EE isn't its goal and jettison those features and not care about CTS.  I think that
would be
> unfortunate as we'd lose the credibility of having certification but it sounds like people
> rather be developing non-J2EE services and features.

At least personally, I think certification is important.  It ensures
at least some minimum level of interop.  But I do agree that we are
far behind the curve in giving  users that next generation development
platform.  And that's what users want.

> > 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!"
> >> -----BEGIN PGP SIGNATURE-----
> >> 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