On 6/19/06, Matt Hogstrom <[EMAIL PROTECTED]> 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 <[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 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.
>
>> > - 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-----
>>
>
>
