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 <[EMAIL PROTECTED]> 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'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.
> - 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 ?
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 :)
> - 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.
> 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.
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-----
