Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of zhanghuangzhu@gmail.com
 designates 64.233.182.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=E2d8xEH/8861CYHxKQCi8VYHJmXvOb6QxHoagUX6XqAwqKVC7//czYZK15mzovyPWDYhOxGDG/2Q3CTi8mghp1YBnRaM74F8pXvE9TUgZHu3R8Dl0CLUOhzkrdGajnRpteB9gHvz1ERVGjssz+R5plw6n5xiKEFg+WnElFbZiqo=
Message-ID: <4d0b24970703050543q53027a3du6d1ff25c4f1edd8b@mail.gmail.com>
Date: Mon, 5 Mar 2007 21:43:16 +0800
From: "Andrew Zhang" <zhanghuangzhu@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [general] Harmony Q2 release requirements
In-Reply-To: <C7122818-A890-4818-B902-62DF0598289E@pobox.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_64786_12723889.1173102196587"
References: <906dd82e0703050053j19350331w9376df0c3d3331ad@mail.gmail.com>
	 <0vq649grqaq.fsf@gmail.com>
	 <906dd82e0703050237u550559c8x9ea7657818fcfe9a@mail.gmail.com>
	 <906dd82e0703050237j19ee9ce2ud5a77cc18c7bd26f@mail.gmail.com>
	 <0vq1wk4rkot.fsf@gmail.com>
	 <C7122818-A890-4818-B902-62DF0598289E@pobox.com>

------=_Part_64786_12723889.1173102196587
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 3/5/07, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
>
> On Mar 5, 2007, at 6:31 AM, Egor Pasko wrote:
>
> > On the 0x290 day of Apache Harmony Mikhail Loenko wrote:
> >> 2007/3/5, Mikhail Loenko <mloenko@gmail.com>:
> >>> 05 Mar 2007 12:30:05 +0300, Egor Pasko <egor.pasko@gmail.com>:
> >>>> On the 0x290 day of Apache Harmony Mikhail Loenko wrote:
> >>>>> According to our high-level roadmap [1] we were going to make our
> >>>>> first release in Q2. Let's define what we would like to see in
> >>>>> our Q2
> >>>>> release. If there are no objections let's discuss what we want
> >>>>> that
> >>>>> release being able to do.
> >>>>>
> >>>>> I suggest that we focus on stability measured by being able to
> >>>>> successfully run a few solid applications and by pass rates for
> >>>>> the
> >>>>> test suites.
> >>>>> So, I think in Q2 we should 1) run reasonable set of
> >>>>> applications 2)
> >>>>> have reasonable testing infrastructure and 3) pass reasonable
> >>>>> set of
> >>>>> test suites.
> >>>>>
> >>>>> Though we will be happy to accept all the patches that fix
> >>>>> existing
> >>>>> problems or add missing functionality, I suggest that people
> >>>>> who hang
> >>>>> around will focus on those scenarios that we will choose here
> >>>>>
> >>>>> Objections? :)
> >>>>>
> >>>>> If there are no objections again, I'd like to propose that we
> >>>>> will target:
> >>>>>
> >>>>> 1) keeping all the enabled apps in the "up" state
> >>>>> (we will create a list of enabled apps and put them all into
> >>>>> cruise control)
> >>>>>
> >>>>> 2) running 2-3 open source server-side software
> >>>>>
> >>>>>
> >>>>> 3) running 2-3 open source developers tools
> >>>>>
> >>>>>
> >>>>> 4) setting up necessary testing infrastructure and having near
> >>>>> 100%
> >>>>> pass rates for the suites we have
> >>>>>
> >>>>>
> >>>>> 5) what about commercial software? Some time ago we agreed that
> >>>>> it's
> >>>>> OK to report failures/regression of commercial software. Should we
> >>>>> have them in the "requirements" to our Q2 release?
> >>>>>
> >>>>> Since currently the most stable platform is Windows/IA32 I suggest
> >>>>> that Harmony Q2 will be released on that specific platform
> >>>>
> >>>> you mean, we have no time for 2 platforms?
> >>>
> >>> I mean we should IMHO make a focus: have superb results on a single
> >>> platform on a limited set of applications rather than have million
> >>> somehow working scenarios
> >>> on a dozen of platforms.
> >>
> >> Does it make sense?
> >
> > I think, limiting ourselves for the next milestone is a good
> > idea. Though, IMHO, limiting ourseles to windows is more of a
> > limitation than of making us focused. It does not take much effort to
> > support Linux with te same priority of bugfixing (if scenarious are
> > pretty automated), but lets people be sure that we are not to break
> > their work in favour to support windows faster.
> >
> > There may be a hybrid strategy: improve on windows, do not break
> > anything on Linux, seems pretty acceptable to me.
>
> I have zero interest in exclusively working on Windows.  None.  Zip.
> Zero.  Nada.
>
> Linux is a peer distro for this project.  It always has been.
>
> To be an open source project that only distributes software for
> closed source ecosystems like Windows is the sort of irony I'd prefer
> not to be associated with :)


+1 :)

geir
>
>
>


-- 
Best regards,
Andrew Zhang

------=_Part_64786_12723889.1173102196587--