Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 46680 invoked from network); 27 Feb 2006 14:29:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 27 Feb 2006 14:29:38 -0000 Received: (qmail 23610 invoked by uid 500); 27 Feb 2006 14:29:23 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 23424 invoked by uid 500); 27 Feb 2006 14:29:22 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 23413 invoked by uid 99); 27 Feb 2006 14:29:22 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Feb 2006 06:29:22 -0800 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: 64.74.244.71 is neither permitted nor denied by domain of geir@pobox.com) Received: from [64.74.244.71] (HELO chi.mobile-health-diary.com) (64.74.244.71) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 27 Feb 2006 06:29:21 -0800 Received: (qmail 28768 invoked from network); 27 Feb 2006 14:28:58 -0000 Received: from 166-220-000-044.mobile.mymmode.com (HELO ?10.56.247.210?) (geir@166.220.0.44) by b014.internal.mobile-health-diary.com with SMTP; 27 Feb 2006 14:28:58 -0000 Message-ID: <4402EDBE.4000306@pobox.com> Date: Mon, 27 Feb 2006 07:17:02 -0500 From: Geir Magnusson Jr Reply-To: geir@pobox.com User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from) References: <906dd82e0602181003i78fc954erdf85942536644be9@mail.gmail.com> <46d21a9a0602200020g217da660laa1c7a282a3e8af4@mail.gmail.com> <906dd82e0602200041r22ab1c7ge8fb360f14c9ec55@mail.gmail.com> <46d21a9a0602200206h74fac9d8v2b99bfc514155a39@mail.gmail.com> <906dd82e0602200220v55490c5x8d4df31903912dac@mail.gmail.com> <46d21a9a0602200335y3e30570ercd2e47762301d9fa@mail.gmail.com> <43F9B75E.9070400@gmail.com> <906dd82e0602200511m79e0c5eekef31a8f0c30e6971@mail.gmail.com> <44022EFA.5010908@pobox.com> <906dd82e0602262325s3dd70c3dj@mail.gmail.com> <46d21a9a0602262353g2d27cd18l7056afe2d7b655dc@mail.gmail.com> In-Reply-To: <46d21a9a0602262353g2d27cd18l7056afe2d7b655dc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Anton Avtamonov wrote: > On 2/27/06, Mikhail Loenko wrote: >> As I understood people in this and similar threads tend to be compatible >> with the Spec rather then with RI (unless we prove that being incompatible >> with RI breaks some existing implementation) >> >> I'm trying to oppose that, I'd to be compatible with RI when in doubt. > > Well, actually you are right. I disagree just to simply copy all the > existing bugs... And as I rememeber I'm not along :-). The main idea > is to follow the guidelines Paulex proposed, i.e. to be reasonable. > Lemme remember Paulex's rules: > >> 1. we should comply with spec >> 2. if RI is contradict with spec, and RI is not logical(sometimes it is >> very obvious, you know what I mean), we comply with RI; else, we discuss >> it case by case. >> 3. if spec is not so clear, we should comply with RI >> 4. if some application failing on that different behavior, we discuss it >> case by case > 5. Log every difference from either the spec or the RI in JIRA. > I believe this approach will give better results: keepping us > compatible with the existing applications and provide more consistent > implementation where possible. Note that according to the rules above > we are not mandatory follow to the spec. > > Btw, releasing new JDK SUN updates some existing methods, sometimes > changing not only internal implementation, but even some behavior. I > suppose they don't run all existing applications to make sure nothing > is broken :-). I don't know how this process is organized, however I > would expect some kind of CCB (Change Control Board) which decide if > it's safe change or not. I suppose our mailing list can act in a very > similar manner. Actually, I think that Sun does have an internal group which does exactly that. I've heard some great stories about the raging fights that have erupted internally due to this process... We'll get to have our great fights here :) geir > > -- > Anton Avtamonov, > Intel Middleware Products Division > >