geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: Request change to RTC Process
Date Tue, 20 Jun 2006 12:44:19 GMT
ROFLMAO :)

See my comments on chimerical (excellent...excellent)

Agree with your other statements.

Hiram Chirino wrote:
> On 6/19/06, Matt Hogstrom <matt@hogstrom.org> 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 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 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 current
>> dialogue which doesn't seem to be improving collaboration and 
>> communication but is actually driving
>> polarization (which I think we're trying to avoid).
>>
>> Hiram Chirino wrote:
>> > On 6/17/06, Rodent of Unusual Size <Ken.Coar@golux.com> 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.  I
>> 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 problems.
>> 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 from:
>>
>> http://dictionary.reference.com/wordoftheday/archive/2003/02/24.html
>>
>> 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
> innovation.
> 

Ok this is awesome :-0  I was wondering if you meant commercial but it was such a perfect
fit at 
chimerical you had me guessing :)

>>
>> >
>> >> >  - 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 components.
>>
>> >> >  - 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
> 
> agreed.
> 
>> 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 would
>> 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 - http://enigmail.mozdev.org
>> >>
>> >> iQCVAwUBRJQ1JZrNPMCpn3XdAQKLAQQAx58qgOEEdnrL79vPuXn8AWYwgrVcwH1j
>> >> X7cnZsvTGmQ4uZW7GiCjjkU2E0H0gGMIRUHFCuV8lul85DectAxE3+4M6pYPAG8v
>> >> wzg8OOYUl4Wmv6s31M1VDBruCseGLh01c+ilYl2G61mM+c+Ppt3dduD/VCqQDeao
>> >> 38KzZSDD1WM=
>> >> =M+w0
>> >> -----END PGP SIGNATURE-----
>> >>
>> >
>> >
>>
> 
> 

Mime
View raw message