geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodent of Unusual Size <Ken.C...@Golux.Com>
Subject Re: Request change to RTC Process
Date Sat, 17 Jun 2006 17:00:21 GMT
Hash: SHA1

Aaron Mulder wrote:
> On 6/17/06, Rodent of Unusual Size <> wrote:
>> If that means things languish for weeks or months, then
>> that's what it means.
> I don't think this is a good idea.

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.

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

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

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.

> Also, it's unmanageable to review large
> changes in detail, so only small changes have any good change of being
> applied in a timely fashion.

Time, time, time.  What is this obsession with getting a
perfect release out according to some arbitrary schedule?

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

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

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


View raw message