geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Request change to RTC Process
Date Sat, 17 Jun 2006 20:35:39 GMT
Is there a code quality issue in this community?

-David

On Jun 17, 2006, at 10:00 AM, Rodent of Unusual Size wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Aaron Mulder wrote:
>> On 6/17/06, Rodent of Unusual Size <Ken.Coar@golux.com> 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!"
> -----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