[general] Harmony Q2 release requirements

[Mikhail Loenko <ml...@gmail.com>]

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

Opinions?

Thanks,
Mikhail

[1] http://harmony.apache.org/roadmap.html

Re: [general] Harmony Q2 release requirements

[Yang Paulex <pa...@gmail.com>]

2007/3/5, Mikhail Loenko <ml...@gmail.com>:
>
> 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.


4) reach reasonable number of public API test coverage.

IIRC  the current method coverage of Harmony test suites is only about 60%,
i.e., almost 40% methods never touched, and I'm not very optimistic on the
public API coverage(this raises another issues, how can we get public API
coverage? seems Emma cannot generated this kind of report easily?).

I understand that there are several reasons, say, several modules come from
existing projects, like yoko, mx4j, etc, but still we can  continuously run
their own test suites on Harmony in some way like Gump, otherwise how could
we confidently say it works fine with Harmony?

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
>
> Opinions?
>
> Thanks,
> Mikhail
>
> [1] http://harmony.apache.org/roadmap.html
>



-- 
Paulex Yang
China Software Development laboratory
IBM

Re: [general] Harmony Q2 release requirements

["Geir Magnusson Jr." <ge...@pobox.com>]

On Mar 5, 2007, at 6:17 AM, Andrew Zhang wrote:

> On 3/5/07, Mikhail Loenko <ml...@gmail.com> wrote:
>>
>> 2007/3/5, Andrew Zhang <zh...@gmail.com>:
>> > Is public API coverage 100% an urgent goal for Harmony Q2 release?
>>
>> It depends... :)
>>
>> If 100% API means "implemented, tested: no bugs" then it's a nice  
>> goal
>> but hardly achievable by Q2.
>>
>> If we compare "100% implemented and somehow works" and "96%  
>> implemented
>> and top N popular apps work fine" then IMHO the second is more  
>> preferable.
>>
>> Personally I'd prefer a JRE that runs my favorite app but misses  
>> some API
>> to a
>> JRE that have 100% completeness but can't start my own application
>>
>> What do you think?
>
>
> 100% agree.
>
> But it seems that some of our predefined goals will be postponed...

This is the key to making a "release train" of developer builds.   
(We've talked about this before).  Namely, we need to stay on track  
with our goal of completion, which I think is important.

geir


>
> Thanks,
>> Mikhail
>>
>>
>> >
>> > On 3/5/07, Mikhail Loenko <ml...@gmail.com> 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
>> > >
>> > > Opinions?
>> > >
>> > > Thanks,
>> > > Mikhail
>> > >
>> > > [1] http://harmony.apache.org/roadmap.html
>> > >
>> >
>> >
>> >
>> > --
>> > Best regards,
>> > Andrew Zhang
>> >
>>
>
>
>
> -- 
> Best regards,
> Andrew Zhang

Re: [general] Harmony Q2 release requirements

[Andrew Zhang <zh...@gmail.com>]

On 3/5/07, Mikhail Loenko <ml...@gmail.com> wrote:
>
> 2007/3/5, Andrew Zhang <zh...@gmail.com>:
> > Is public API coverage 100% an urgent goal for Harmony Q2 release?
>
> It depends... :)
>
> If 100% API means "implemented, tested: no bugs" then it's a nice goal
> but hardly achievable by Q2.
>
> If we compare "100% implemented and somehow works" and "96% implemented
> and top N popular apps work fine" then IMHO the second is more preferable.
>
> Personally I'd prefer a JRE that runs my favorite app but misses some API
> to a
> JRE that have 100% completeness but can't start my own application
>
> What do you think?


100% agree.

But it seems that some of our predefined goals will be postponed...

Thanks,
> Mikhail
>
>
> >
> > On 3/5/07, Mikhail Loenko <ml...@gmail.com> 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
> > >
> > > Opinions?
> > >
> > > Thanks,
> > > Mikhail
> > >
> > > [1] http://harmony.apache.org/roadmap.html
> > >
> >
> >
> >
> > --
> > Best regards,
> > Andrew Zhang
> >
>



-- 
Best regards,
Andrew Zhang

Re: [general] Harmony Q2 release requirements

[Mikhail Loenko <ml...@gmail.com>]

2007/3/5, Andrew Zhang <zh...@gmail.com>:
> Is public API coverage 100% an urgent goal for Harmony Q2 release?

It depends... :)

If 100% API means "implemented, tested: no bugs" then it's a nice goal
but hardly achievable by Q2.

If we compare "100% implemented and somehow works" and "96% implemented
and top N popular apps work fine" then IMHO the second is more preferable.

Personally I'd prefer a JRE that runs my favorite app but misses some API to a
JRE that have 100% completeness but can't start my own application

What do you think?

Thanks,
Mikhail


>
> On 3/5/07, Mikhail Loenko <ml...@gmail.com> 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
> >
> > Opinions?
> >
> > Thanks,
> > Mikhail
> >
> > [1] http://harmony.apache.org/roadmap.html
> >
>
>
>
> --
> Best regards,
> Andrew Zhang
>

Re: [general] Harmony Q2 release requirements

[Andrew Zhang <zh...@gmail.com>]

On 3/6/07, Stepan Mishura <st...@gmail.com> wrote:
>
> On 3/5/07, Geir Magnusson Jr. wrote:
> >
> >
> > On Mar 5, 2007, at 5:53 AM, Andrew Zhang wrote:
> >
> > > Is public API coverage 100% an urgent goal for Harmony Q2 release?
> >
> > It's our goal for a 1.0 release, and the ultimate goal for the
> > project, so I don't see why we'd relax our efforts to make that happen.
>
>
> IMHO, we are not going to forget about our ultimate goal - 100% public
> API.
> "Intermediate" (or "developers", if you like) release is required just to
> show Harmony's progress and quality of existing code by having
> successfully
> running some apps scenarios and/or theirs tests (that my understanding of
> Mikhail's proposal). That helps to see where we are and what should be
> done
> first (for example, complete SQL API).
>
> Sure, every effort for completing public API is very valuable for us.
> Andrew, keep up your great work!


Thanks, Stepan, Harmony-3271 has been there. :)

-Stepan.
>
> geir
> >
> >
> > >
> > > On 3/5/07, Mikhail Loenko <ml...@gmail.com> 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
> > >>
> > >> Opinions?
> > >>
> > >> Thanks,
> > >> Mikhail
> > >>
> > >> [1] http://harmony.apache.org/roadmap.html
> > >>
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew Zhang
> >
> >
>
>
> --
> Stepan Mishura
> Intel Enterprise Solutions Software Division
>



-- 
Best regards,
Andrew Zhang

Re: [general] Harmony Q2 release requirements

["Geir Magnusson Jr." <ge...@pobox.com>]

On Mar 5, 2007, at 9:43 PM, Stepan Mishura wrote:

> On 3/5/07, Geir Magnusson Jr. wrote:
>>
>>
>> On Mar 5, 2007, at 5:53 AM, Andrew Zhang wrote:
>>
>> > Is public API coverage 100% an urgent goal for Harmony Q2 release?
>>
>> It's our goal for a 1.0 release, and the ultimate goal for the
>> project, so I don't see why we'd relax our efforts to make that  
>> happen.
>
>
> IMHO, we are not going to forget about our ultimate goal - 100%  
> public API.
> "Intermediate" (or "developers", if you like) release is required  
> just to
> show Harmony's progress and quality of existing code by having  
> successfully
> running some apps scenarios and/or theirs tests (that my  
> understanding of
> Mikhail's proposal). That helps to see where we are and what should  
> be done
> first (for example, complete SQL API).

Lets not get distracted by the name.  Clearly, we aren't talking 1.0  
until we hit 100% an pass the JCK.  So lets just call them "builds",  
and always shoot for as high-quality as we can.

We need to start building the process and practice in the project for  
doing this - for doing the build, ensuring the docs are right,  
ensuring it's well tested, doing better packaging than a zip and tgz,  
etc.

I think we have a reasonable base of code to build on to start doing  
this.

geir


>
> Sure, every effort for completing public API is very valuable for us.
> Andrew, keep up your great work!
>
> -Stepan.
>
> geir
>>
>>
>> >
>> > On 3/5/07, Mikhail Loenko <ml...@gmail.com> 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
>> >>
>> >> Opinions?
>> >>
>> >> Thanks,
>> >> Mikhail
>> >>
>> >> [1] http://harmony.apache.org/roadmap.html
>> >>
>> >
>> >
>> >
>> > --
>> > Best regards,
>> > Andrew Zhang
>>
>>
>
>
> -- 
> Stepan Mishura
> Intel Enterprise Solutions Software Division

Re: [general] Harmony Q2 release requirements

[Mikhail Loenko <ml...@gmail.com>]

2007/3/6, Stepan Mishura <st...@gmail.com>:
> On 3/5/07, Geir Magnusson Jr. wrote:
> >
> >
> > On Mar 5, 2007, at 5:53 AM, Andrew Zhang wrote:
> >
> > > Is public API coverage 100% an urgent goal for Harmony Q2 release?
> >
> > It's our goal for a 1.0 release, and the ultimate goal for the
> > project, so I don't see why we'd relax our efforts to make that happen.
>
>
> IMHO, we are not going to forget about our ultimate goal - 100% public API.
> "Intermediate" (or "developers", if you like) release is required just to
> show Harmony's progress and quality of existing code by having successfully
> running some apps scenarios and/or theirs tests (that my understanding of
> Mikhail's proposal). That helps to see where we are and what should be done
> first (for example, complete SQL API).
>
> Sure, every effort for completing public API is very valuable for us.
> Andrew, keep up your great work!

+1

Thanks,
Mikhail

>
> -Stepan.
>
> geir
> >
> >
> > >
> > > On 3/5/07, Mikhail Loenko <ml...@gmail.com> 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
> > >>
> > >> Opinions?
> > >>
> > >> Thanks,
> > >> Mikhail
> > >>
> > >> [1] http://harmony.apache.org/roadmap.html
> > >>
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew Zhang
> >
> >
>
>
> --
> Stepan Mishura
> Intel Enterprise Solutions Software Division
>

Re: [general] Harmony Q2 release requirements

[Stepan Mishura <st...@gmail.com>]

On 3/5/07, Geir Magnusson Jr. wrote:
>
>
> On Mar 5, 2007, at 5:53 AM, Andrew Zhang wrote:
>
> > Is public API coverage 100% an urgent goal for Harmony Q2 release?
>
> It's our goal for a 1.0 release, and the ultimate goal for the
> project, so I don't see why we'd relax our efforts to make that happen.


IMHO, we are not going to forget about our ultimate goal - 100% public API.
"Intermediate" (or "developers", if you like) release is required just to
show Harmony's progress and quality of existing code by having successfully
running some apps scenarios and/or theirs tests (that my understanding of
Mikhail's proposal). That helps to see where we are and what should be done
first (for example, complete SQL API).

Sure, every effort for completing public API is very valuable for us.
Andrew, keep up your great work!

-Stepan.

geir
>
>
> >
> > On 3/5/07, Mikhail Loenko <ml...@gmail.com> 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
> >>
> >> Opinions?
> >>
> >> Thanks,
> >> Mikhail
> >>
> >> [1] http://harmony.apache.org/roadmap.html
> >>
> >
> >
> >
> > --
> > Best regards,
> > Andrew Zhang
>
>


-- 
Stepan Mishura
Intel Enterprise Solutions Software Division

Re: [general] Harmony Q2 release requirements

["Geir Magnusson Jr." <ge...@pobox.com>]

On Mar 5, 2007, at 5:53 AM, Andrew Zhang wrote:

> Is public API coverage 100% an urgent goal for Harmony Q2 release?

It's our goal for a 1.0 release, and the ultimate goal for the  
project, so I don't see why we'd relax our efforts to make that happen.

geir


>
> On 3/5/07, Mikhail Loenko <ml...@gmail.com> 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
>>
>> Opinions?
>>
>> Thanks,
>> Mikhail
>>
>> [1] http://harmony.apache.org/roadmap.html
>>
>
>
>
> -- 
> Best regards,
> Andrew Zhang

Re: [general] Harmony Q2 release requirements

[Andrew Zhang <zh...@gmail.com>]

Is public API coverage 100% an urgent goal for Harmony Q2 release?

On 3/5/07, Mikhail Loenko <ml...@gmail.com> 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
>
> Opinions?
>
> Thanks,
> Mikhail
>
> [1] http://harmony.apache.org/roadmap.html
>



-- 
Best regards,
Andrew Zhang

Re: [general] Harmony Q2 release requirements

[Yang Paulex <pa...@gmail.com>]

2007/3/6, Stepan Mishura <st...@gmail.com>:
>
> On 3/5/07, Mikhail Loenko wrote:
> >
> > <SNIP>
> > > >>>>> 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 :)
> >
> > Nobody is talking about being a project for Windows only.
> >
> > The idea is going deep first and extend in deapth next.
> >
> > If we try to have everything before we have something we will have
> > nothing:
> > if we try to have presense on each platform before we are solid on at
> > least
> > one platform we will lose: for each platform there always be "another"
> > implementation that is better.
> >
> > Instead we should stick to some specific platform, make it solid and
> > then extend
>
>
> I don't see a big issue here to ague about - my impression is that most of
> the issues currently we have are OS-independent. Why not focus on
> architecture rather then OS? We've already implementation for
> Windows/Linux.
> I've heard that Windows implementation a bit more optimized (VM guys
> please
> correct me if I'm wrong). But is it really doesn't matter, IMHO, they both
> are quite solid. And I think that improving both of them won't double
> required efforts (compared to improving implementation for one selected
> OS).
>
>
> Let's say that x86 (Windows/Linux) is our primary focus. And next goal is
> to
> be solid on x86-64 architecture.


+1

Thanks,
> Stepan Mishura
> Intel Enterprise Solutions Software Division
>



-- 
Paulex Yang
China Software Development laboratory
IBM

Re: [general] Harmony Q2 release requirements

["Geir Magnusson Jr." <ge...@pobox.com>]

On Mar 6, 2007, at 12:31 AM, Stepan Mishura wrote:

> On 3/5/07, Mikhail Loenko wrote:
>>
>> <SNIP>
>> > >>>>> 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 :)
>>
>> Nobody is talking about being a project for Windows only.
>>
>> The idea is going deep first and extend in deapth next.
>>
>> If we try to have everything before we have something we will have
>> nothing:
>> if we try to have presense on each platform before we are solid on at
>> least
>> one platform we will lose: for each platform there always be  
>> "another"
>> implementation that is better.
>>
>> Instead we should stick to some specific platform, make it solid and
>> then extend
>
>
> I don't see a big issue here to ague about - my impression is that  
> most of
> the issues currently we have are OS-independent. Why not focus on
> architecture rather then OS? We've already implementation for  
> Windows/Linux.
> I've heard that Windows implementation a bit more optimized (VM  
> guys please
> correct me if I'm wrong). But is it really doesn't matter, IMHO,  
> they both
> are quite solid. And I think that improving both of them won't double
> required efforts (compared to improving implementation for one  
> selected OS).

Exactly.

>
>
> Let's say that x86 (Windows/Linux) is our primary focus. And next  
> goal is to
> be solid on x86-64 architecture.
>
> Thanks,
> Stepan Mishura
> Intel Enterprise Solutions Software Division

Re: [general] Harmony Q2 release requirements

[Naveen Neelakantam <ne...@uiuc.edu>]

+1

On Mar 6, 2007, at 12:08 AM, Kalpak Gadre wrote:

> +1
>> I don't see a big issue here to ague about - my impression is that  
>> most of
>> the issues currently we have are OS-independent. Why not focus on
>> architecture rather then OS? We've already implementation for  
>> Windows/Linux.
>> I've heard that Windows implementation a bit more optimized (VM  
>> guys please
>> correct me if I'm wrong). But is it really doesn't matter, IMHO,  
>> they both
>> are quite solid. And I think that improving both of them won't double
>> required efforts (compared to improving implementation for one  
>> selected OS).
>>
>>
>> Let's say that x86 (Windows/Linux) is our primary focus. And next  
>> goal is to
>> be solid on x86-64 architecture.
>

Re: [general] Harmony Q2 release requirements

[Kalpak Gadre <ka...@gmail.com>]

+1
> I don't see a big issue here to ague about - my impression is that 
> most of
> the issues currently we have are OS-independent. Why not focus on
> architecture rather then OS? We've already implementation for 
> Windows/Linux.
> I've heard that Windows implementation a bit more optimized (VM guys 
> please
> correct me if I'm wrong). But is it really doesn't matter, IMHO, they 
> both
> are quite solid. And I think that improving both of them won't double
> required efforts (compared to improving implementation for one 
> selected OS).
>
>
> Let's say that x86 (Windows/Linux) is our primary focus. And next goal 
> is to
> be solid on x86-64 architecture.

Re: [general] Harmony Q2 release requirements

[Stepan Mishura <st...@gmail.com>]

On 3/5/07, Mikhail Loenko wrote:
>
> <SNIP>
> > >>>>> 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 :)
>
> Nobody is talking about being a project for Windows only.
>
> The idea is going deep first and extend in deapth next.
>
> If we try to have everything before we have something we will have
> nothing:
> if we try to have presense on each platform before we are solid on at
> least
> one platform we will lose: for each platform there always be "another"
> implementation that is better.
>
> Instead we should stick to some specific platform, make it solid and
> then extend


I don't see a big issue here to ague about - my impression is that most of
the issues currently we have are OS-independent. Why not focus on
architecture rather then OS? We've already implementation for Windows/Linux.
I've heard that Windows implementation a bit more optimized (VM guys please
correct me if I'm wrong). But is it really doesn't matter, IMHO, they both
are quite solid. And I think that improving both of them won't double
required efforts (compared to improving implementation for one selected OS).


Let's say that x86 (Windows/Linux) is our primary focus. And next goal is to
be solid on x86-64 architecture.

Thanks,
Stepan Mishura
Intel Enterprise Solutions Software Division

Re: [general] Harmony Q2 release requirements

[Mikhail Loenko <ml...@gmail.com>]

2007/3/5, Geir Magnusson Jr. <ge...@pobox.com>:
>
> 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 <ml...@gmail.com>:
> >>> 05 Mar 2007 12:30:05 +0300, Egor Pasko <eg...@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 :)

Nobody is talking about being a project for Windows only.

The idea is going deep first and extend in deapth next.

If we try to have everything before we have something we will have nothing:
if we try to have presense on each platform before we are solid on at least
one platform we will lose: for each platform there always be "another"
implementation that is better.

Instead we should stick to some specific platform, make it solid and
then extend

Thanks,
Mikhail

>
> geir
>
>
>

Re: [general] Harmony Q2 release requirements

[Egor Pasko <eg...@gmail.com>]

On the 0x290 day of Apache Harmony Geir Magnusson, Jr. 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 <ml...@gmail.com>:
> >>> 05 Mar 2007 12:30:05 +0300, Egor Pasko <eg...@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.

+1

> 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 :)
> 
> geir
> 
> 
> 

-- 
Egor Pasko

Re: [general] Harmony Q2 release requirements

[Andrew Zhang <zh...@gmail.com>]

On 3/5/07, Geir Magnusson Jr. <ge...@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 <ml...@gmail.com>:
> >>> 05 Mar 2007 12:30:05 +0300, Egor Pasko <eg...@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

Re: [general] Harmony Q2 release requirements

[Peter Novodvorsky <pe...@gmail.com>]

On 3/5/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> 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.

Re: [general] Harmony Q2 release requirements

["Geir Magnusson Jr." <ge...@pobox.com>]

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 <ml...@gmail.com>:
>>> 05 Mar 2007 12:30:05 +0300, Egor Pasko <eg...@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 :)

geir

Re: [general] Harmony Q2 release requirements

[Mikhail Loenko <ml...@gmail.com>]

05 Mar 2007 14:31:14 +0300, Egor Pasko <eg...@gmail.com>:
> On the 0x290 day of Apache Harmony Mikhail Loenko wrote:
> > 2007/3/5, Mikhail Loenko <ml...@gmail.com>:
> > > 05 Mar 2007 12:30:05 +0300, Egor Pasko <eg...@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.

+1

We should not break anything we already have.
Moreover we should further develop it and accept patches that improve
other platforms, API coverage, enable not-very-popular apps, etc

But we still need to keep the focus in our minds...

Thanks,
Mikhail

>
> --
> Egor Pasko
>
>

Re: [general] Harmony Q2 release requirements

[Egor Pasko <eg...@gmail.com>]

On the 0x290 day of Apache Harmony Mikhail Loenko wrote:
> 2007/3/5, Mikhail Loenko <ml...@gmail.com>:
> > 05 Mar 2007 12:30:05 +0300, Egor Pasko <eg...@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.

-- 
Egor Pasko

Re: [general] Harmony Q2 release requirements

[Mikhail Loenko <ml...@gmail.com>]

2007/3/5, Mikhail Loenko <ml...@gmail.com>:
> 05 Mar 2007 12:30:05 +0300, Egor Pasko <eg...@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?


>
> Thanks,
> Mikhail
>
> >
> > --
> > Egor Pasko
> >
> >
>

Re: [general] Harmony Q2 release requirements

["Geir Magnusson Jr." <ge...@pobox.com>]

On Mar 5, 2007, at 5:37 AM, Mikhail Loenko wrote:

> 05 Mar 2007 12:30:05 +0300, Egor Pasko <eg...@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.

No.  I disagree strongly.  We aren't talking about "a dozen".  We're  
talking 2-3

geir

>
> Thanks,
> Mikhail
>
>>
>> --
>> Egor Pasko
>>
>>

Re: [general] Harmony Q2 release requirements

[Mikhail Loenko <ml...@gmail.com>]

05 Mar 2007 12:30:05 +0300, Egor Pasko <eg...@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.

Thanks,
Mikhail

>
> --
> Egor Pasko
>
>

Re: [general] Harmony Q2 release requirements

["Geir Magnusson Jr." <ge...@pobox.com>]

On Mar 5, 2007, at 4:30 AM, Egor Pasko wrote:

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

Yes we can do at least win/32, linux/32 and hopefully what we have  
for 64 bit as well.

geir

>
> -- 
> Egor Pasko
>

Re: [general] Harmony Q2 release requirements

[Egor Pasko <eg...@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?

-- 
Egor Pasko

Re: [general] Harmony Q2 release requirements

["Geir Magnusson Jr." <ge...@pobox.com>]

On Mar 6, 2007, at 8:20 AM, Jin Mingjian wrote:

> Hi, all
>
> I'm not very optimistic with Q2 target. Before several days, I've
> tested the latest Harmony JDK (with default DRLVM) in the website,
> then I could not bootup my Eclipse3.3 M5 even(the latest Milestone of
> Eclipse). So I think we should put more carefulness into Q2 target.
> And the mainstream Applications may be tested in some way.

Lets not oversell the "Q2 target" as a be-all-end-all target.  We  
have a continuous target for creating good software, so a sequence of  
releases (monthly?) will let us put stakes in the ground, plan out  
what we want to deliver, and make it clear to users what they can do  
with the software.

I'm going to start a new thread to get us out of this hole.

geir

Re: [general] Harmony Q2 release requirements

[Jin Mingjian <ji...@gmail.com>]

Hi, all

I'm not very optimistic with Q2 target. Before several days, I've
tested the latest Harmony JDK (with default DRLVM) in the website,
then I could not bootup my Eclipse3.3 M5 even(the latest Milestone of
Eclipse). So I think we should put more carefulness into Q2 target.
And the mainstream Applications may be tested in some way.

Jin

Re: [general] Harmony Q2 release requirements

[Mikhail Loenko <ml...@gmail.com>]

+1

Thanks,
Mikhail

2007/3/6, Morozova, Nadezhda <na...@intel.com>:
> Hi,
> Since the discussion is going on actively, I've thought of gathering the
> ideas and publishing on wiki.  What do you say?
>
> Cheers,
> Nadya
>
> >-----Original Message-----
> >From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
> >Sent: Tuesday, March 06, 2007 12:14 PM
> >To: dev@harmony.apache.org
> >Subject: Re: [general] Harmony Q2 release requirements
> >
> >2007/3/5, Mikhail Loenko <ml...@gmail.com>:
> >> 2007/3/5, Alexey Petrenko <al...@gmail.com>:
> >> > 2007/3/5, Mikhail Loenko <ml...@gmail.com>:
> >> > > 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? :)
> >> > No objections! :)
> >> > We definitely need a milestone since milestones helps to keep us
> and
> >> > Harmony in good shape.
> >> >
> >> > >
> >> > > 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?
> >> >
> >> > I think that we also need performance targets: run some benchmarks
> and
> >> > demonstrate reasonable results.
> >> > We are using Dacapo and SciMark now [1].
> >>
> >> Agreed, we definitely need performance goals
> >>
> >> >
> >> > Do we need some additional benchmarks? And what will the reasonable
> >> > target results?
> >>
> >> No worse than RI 6.0 ? Do you think we can achieve that in Q2? :)
> >I think that this can be achieved for a limited set of benchmarks.
> >
> >SY, Alexey
>

RE: [general] Harmony Q2 release requirements

["Morozova, Nadezhda" <na...@intel.com>]

Hi,
Since the discussion is going on actively, I've thought of gathering the
ideas and publishing on wiki.  What do you say?

Cheers, 
Nadya
 
>-----Original Message-----
>From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
>Sent: Tuesday, March 06, 2007 12:14 PM
>To: dev@harmony.apache.org
>Subject: Re: [general] Harmony Q2 release requirements
>
>2007/3/5, Mikhail Loenko <ml...@gmail.com>:
>> 2007/3/5, Alexey Petrenko <al...@gmail.com>:
>> > 2007/3/5, Mikhail Loenko <ml...@gmail.com>:
>> > > 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? :)
>> > No objections! :)
>> > We definitely need a milestone since milestones helps to keep us
and
>> > Harmony in good shape.
>> >
>> > >
>> > > 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?
>> >
>> > I think that we also need performance targets: run some benchmarks
and
>> > demonstrate reasonable results.
>> > We are using Dacapo and SciMark now [1].
>>
>> Agreed, we definitely need performance goals
>>
>> >
>> > Do we need some additional benchmarks? And what will the reasonable
>> > target results?
>>
>> No worse than RI 6.0 ? Do you think we can achieve that in Q2? :)
>I think that this can be achieved for a limited set of benchmarks.
>
>SY, Alexey

Re: [general] Harmony Q2 release requirements

[Alexey Petrenko <al...@gmail.com>]

2007/3/5, Mikhail Loenko <ml...@gmail.com>:
> 2007/3/5, Alexey Petrenko <al...@gmail.com>:
> > 2007/3/5, Mikhail Loenko <ml...@gmail.com>:
> > > 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? :)
> > No objections! :)
> > We definitely need a milestone since milestones helps to keep us and
> > Harmony in good shape.
> >
> > >
> > > 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?
> >
> > I think that we also need performance targets: run some benchmarks and
> > demonstrate reasonable results.
> > We are using Dacapo and SciMark now [1].
>
> Agreed, we definitely need performance goals
>
> >
> > Do we need some additional benchmarks? And what will the reasonable
> > target results?
>
> No worse than RI 6.0 ? Do you think we can achieve that in Q2? :)
I think that this can be achieved for a limited set of benchmarks.

SY, Alexey

Re: [general] Harmony Q2 release requirements

[Mikhail Loenko <ml...@gmail.com>]

2007/3/5, Alexey Petrenko <al...@gmail.com>:
> 2007/3/5, Mikhail Loenko <ml...@gmail.com>:
> > 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? :)
> No objections! :)
> We definitely need a milestone since milestones helps to keep us and
> Harmony in good shape.
>
> >
> > 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?
>
> I think that we also need performance targets: run some benchmarks and
> demonstrate reasonable results.
> We are using Dacapo and SciMark now [1].

Agreed, we definitely need performance goals

>
> Do we need some additional benchmarks? And what will the reasonable
> target results?

No worse than RI 6.0 ? Do you think we can achieve that in Q2? :)

Thanks,
Mikhail


>
> > Since currently the most stable platform is Windows/IA32 I suggest
> > that Harmony Q2 will be released on that specific platform
> +1
>
> SY, Alexey
>
> [1] http://harmony.apache.org/performance.html
>

Re: [general] Harmony Q2 release requirements

[Alexey Petrenko <al...@gmail.com>]

2007/3/5, Mikhail Loenko <ml...@gmail.com>:
> 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? :)
No objections! :)
We definitely need a milestone since milestones helps to keep us and
Harmony in good shape.

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

I think that we also need performance targets: run some benchmarks and
demonstrate reasonable results.
We are using Dacapo and SciMark now [1].

Do we need some additional benchmarks? And what will the reasonable
target results?

> Since currently the most stable platform is Windows/IA32 I suggest
> that Harmony Q2 will be released on that specific platform
+1

SY, Alexey

[1] http://harmony.apache.org/performance.html

Re: [general] Harmony Q2 release requirements

[Stepan Mishura <st...@gmail.com>]

On 3/5/07, 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? :)


I agree that we need to have a milestone.

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)


Having several apps successfully and stably running on Harmony is a good aim
for the release. I can focus on enabling and running regularly the apps that
make sense as we decide here.

2) running 2-3 open source server-side software


What about JBoss and BEA WebLogic?

3) running 2-3 open source developers tools


The first thing that spreads to my mind is Eclipse – IMHO it's very popular
developer's soft. We already have Eclipse hello world application testing
scenario running under CC. And we have a patch that integrates Eclipse unit
tests to build-and-test infra.

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?


I think it's OK to try commercial apps – having some commercial apps enabled
is a good indicator for Harmony. I think we should pick up some apps, try to
run them and see if everything goes smooth. Is there a good candidate?

Thanks,
Stepan.

Since currently the most stable platform is Windows/IA32 I suggest
> that Harmony Q2 will be released on that specific platform
>
> Opinions?
>
> Thanks,
> Mikhail
>
> [1] http://harmony.apache.org/roadmap.html
>



-- 
Stepan Mishura
Intel Enterprise Solutions Software Division

RE: [general] Harmony Q2 release requirements

["Morozova, Nadezhda" <na...@intel.com>]

Hi all,
For everyone's convenience and not to lose any ideas, I've tried to sum
up this thread on a wiki page.
http://wiki.apache.org/harmony/Harmony_Q2_Milestone 

Cheers, 
Nadya
 
>-----Original Message-----
>From: Geir Magnusson Jr. [mailto:geir@pobox.com]
>Sent: Tuesday, March 06, 2007 5:36 PM
>To: dev@harmony.apache.org
>Subject: Re: [general] Harmony Q2 release requirements
>
>
>On Mar 6, 2007, at 8:50 AM, Mikhail Loenko wrote:
>
>> 2007/3/6, Geir Magnusson Jr. <ge...@pobox.com>:
>>>
>>> I think that each release should be well tested and documented.  We
>>> should do the release train, with each release getting better and
>>> better - no regressions unless we all agree there's a darn good
>>> reason for it.
>>
>> What would be the interval between the releases in the "train"?
>> If it's 3 months then yes we can have such a train. If it's a week
>> then
>> we all will be busy with releases and won' have time for coding
>
>Monthly?  I think we can play it by ear - move forward, and adjust as
>we learn things.  Also, we need to work it out so things don't grind
>to a halt at release time.
>
>I'll start a second thread to discuss this approach.
>
>geir

Re: [general] Harmony Q2 release requirements

["Geir Magnusson Jr." <ge...@pobox.com>]

On Mar 6, 2007, at 8:50 AM, Mikhail Loenko wrote:

> 2007/3/6, Geir Magnusson Jr. <ge...@pobox.com>:
>>
>> I think that each release should be well tested and documented.  We
>> should do the release train, with each release getting better and
>> better - no regressions unless we all agree there's a darn good
>> reason for it.
>
> What would be the interval between the releases in the "train"?
> If it's 3 months then yes we can have such a train. If it's a week  
> then
> we all will be busy with releases and won' have time for coding

Monthly?  I think we can play it by ear - move forward, and adjust as  
we learn things.  Also, we need to work it out so things don't grind  
to a halt at release time.

I'll start a second thread to discuss this approach.

geir

Re: [general] Harmony Q2 release requirements

[Mikhail Loenko <ml...@gmail.com>]

2007/3/6, Geir Magnusson Jr. <ge...@pobox.com>:
>
> On Mar 5, 2007, at 9:44 AM, Mikhail Loenko wrote:
>
> > 2007/3/5, Geir Magnusson Jr. <ge...@pobox.com>:
> >>
> >> On Mar 5, 2007, at 3:53 AM, 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.
> >>
> >> That was a long distance guess, not The Law :)
> >>
> >> Now that we are closer, we probably need to re-assess.  For example,
> >> I'd much rather see a sequence of "developer releases" leading up to
> >> our 1.0, whenever that will be, with each dev release building on the
> >> last.
> >>
> >> >
> >> > 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.
> >>
> >> Absolutely.  I thought that is what we're doing already :)
> >>
> >>
> >> > 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.
> >>
> >> Yes
> >>
> >> >
> >> > 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
> >>
> >> I have no idea what that means.  We still need to continue completion
> >> - our goal is a compatible implementation of Java SE 5, so we need to
> >> continue working in that direction.
> >
> > The direction is diverse. We may try to do everything at once
> > but may do some things first and some - next. They call it
> > priorities :)
>
> Priorities are fine - but the goal is Java SE 5, so we should then
> simply prioritize our path to that goal.
>
> >
> >
> >>
> >> >
> >> > 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)
> >>
> >> +1
> >>
> >> >
> >> > 2) running 2-3 open source server-side software
> >> >
> >>
> >> +1
> >>
> >> >
> >> > 3) running 2-3 open source developers tools
> >>
> >> +1
> >>
> >> >
> >> >
> >> > 4) setting up necessary testing infrastructure and having near 100%
> >> > pass rates for the suites we have
> >>
> >> Sure, and this is already in progress.
> >>
> >> >
> >> >
> >> > 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?
> >>
> >> Again, I don't support the idea of One Big Q2 release.  I'd rather
> >> see us setup a sequence of developer releases making incremental
> >> improvement.
> >
> > I'm not against that sequence. But we should have something for which
> > we will say that it's able to do this and that. We want be able to
> > provide
> > good documentation for each release in the sequence. We will release
> > something better tested, better documented, etc than just a release
> > in the sequence. This will be a Q2 release.
>
> I think that each release should be well tested and documented.  We
> should do the release train, with each release getting better and
> better - no regressions unless we all agree there's a darn good
> reason for it.

What would be the interval between the releases in the "train"?
If it's 3 months then yes we can have such a train. If it's a week then
we all will be busy with releases and won' have time for coding

Thanks,
Mikhail


>
> >
> >> >
> >> > Since currently the most stable platform is Windows/IA32 I suggest
> >> > that Harmony Q2 will be released on that specific platform
> >>
> >> Of course win32, but we also need to do the release on at least one
> >> flavor of linux.
> >
> > Of course. But not necessarily at the same time.
>
> Sorry - I disagree with you.  I really think that we need to have a
> release for not just the windows platform.  Our best chance for
> widespread distribution is going to be linux.  There are multiple
> packaging streams we can take advantage of (apt, rpm, yum, whatever
> Suse uses...) to get our software out in front of users that need a
> free/open Java runtime.  Clearly microsoft isn't going to help us
> here, and the windows crowd doesn't care as much about having a free/
> open runtime to use.
>
> Lets be strategic about this.
>
> geir
>
>
>
>
> >
> > Thanks,
> > Mikhail
> >
> >
> >>
> >> geir
> >>
> >> >
> >> > Opinions?
> >> >
> >> > Thanks,
> >> > Mikhail
> >> >
> >> > [1] http://harmony.apache.org/roadmap.html
> >>
> >>
>
>

Re: [general] Harmony Q2 release requirements

["Geir Magnusson Jr." <ge...@pobox.com>]

On Mar 5, 2007, at 9:44 AM, Mikhail Loenko wrote:

> 2007/3/5, Geir Magnusson Jr. <ge...@pobox.com>:
>>
>> On Mar 5, 2007, at 3:53 AM, 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.
>>
>> That was a long distance guess, not The Law :)
>>
>> Now that we are closer, we probably need to re-assess.  For example,
>> I'd much rather see a sequence of "developer releases" leading up to
>> our 1.0, whenever that will be, with each dev release building on the
>> last.
>>
>> >
>> > 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.
>>
>> Absolutely.  I thought that is what we're doing already :)
>>
>>
>> > 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.
>>
>> Yes
>>
>> >
>> > 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
>>
>> I have no idea what that means.  We still need to continue completion
>> - our goal is a compatible implementation of Java SE 5, so we need to
>> continue working in that direction.
>
> The direction is diverse. We may try to do everything at once
> but may do some things first and some - next. They call it  
> priorities :)

Priorities are fine - but the goal is Java SE 5, so we should then  
simply prioritize our path to that goal.

>
>
>>
>> >
>> > 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)
>>
>> +1
>>
>> >
>> > 2) running 2-3 open source server-side software
>> >
>>
>> +1
>>
>> >
>> > 3) running 2-3 open source developers tools
>>
>> +1
>>
>> >
>> >
>> > 4) setting up necessary testing infrastructure and having near 100%
>> > pass rates for the suites we have
>>
>> Sure, and this is already in progress.
>>
>> >
>> >
>> > 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?
>>
>> Again, I don't support the idea of One Big Q2 release.  I'd rather
>> see us setup a sequence of developer releases making incremental
>> improvement.
>
> I'm not against that sequence. But we should have something for which
> we will say that it's able to do this and that. We want be able to  
> provide
> good documentation for each release in the sequence. We will release
> something better tested, better documented, etc than just a release
> in the sequence. This will be a Q2 release.

I think that each release should be well tested and documented.  We  
should do the release train, with each release getting better and  
better - no regressions unless we all agree there's a darn good  
reason for it.

>
>> >
>> > Since currently the most stable platform is Windows/IA32 I suggest
>> > that Harmony Q2 will be released on that specific platform
>>
>> Of course win32, but we also need to do the release on at least one
>> flavor of linux.
>
> Of course. But not necessarily at the same time.

Sorry - I disagree with you.  I really think that we need to have a  
release for not just the windows platform.  Our best chance for  
widespread distribution is going to be linux.  There are multiple  
packaging streams we can take advantage of (apt, rpm, yum, whatever  
Suse uses...) to get our software out in front of users that need a  
free/open Java runtime.  Clearly microsoft isn't going to help us  
here, and the windows crowd doesn't care as much about having a free/ 
open runtime to use.

Lets be strategic about this.

geir




>
> Thanks,
> Mikhail
>
>
>>
>> geir
>>
>> >
>> > Opinions?
>> >
>> > Thanks,
>> > Mikhail
>> >
>> > [1] http://harmony.apache.org/roadmap.html
>>
>>

Re: [general] Harmony Q2 release requirements

[Mikhail Loenko <ml...@gmail.com>]

2007/3/5, Geir Magnusson Jr. <ge...@pobox.com>:
>
> On Mar 5, 2007, at 3:53 AM, 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.
>
> That was a long distance guess, not The Law :)
>
> Now that we are closer, we probably need to re-assess.  For example,
> I'd much rather see a sequence of "developer releases" leading up to
> our 1.0, whenever that will be, with each dev release building on the
> last.
>
> >
> > 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.
>
> Absolutely.  I thought that is what we're doing already :)
>
>
> > 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.
>
> Yes
>
> >
> > 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
>
> I have no idea what that means.  We still need to continue completion
> - our goal is a compatible implementation of Java SE 5, so we need to
> continue working in that direction.

The direction is diverse. We may try to do everything at once
but may do some things first and some - next. They call it priorities :)


>
> >
> > 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)
>
> +1
>
> >
> > 2) running 2-3 open source server-side software
> >
>
> +1
>
> >
> > 3) running 2-3 open source developers tools
>
> +1
>
> >
> >
> > 4) setting up necessary testing infrastructure and having near 100%
> > pass rates for the suites we have
>
> Sure, and this is already in progress.
>
> >
> >
> > 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?
>
> Again, I don't support the idea of One Big Q2 release.  I'd rather
> see us setup a sequence of developer releases making incremental
> improvement.

I'm not against that sequence. But we should have something for which
we will say that it's able to do this and that. We want be able to provide
good documentation for each release in the sequence. We will release
something better tested, better documented, etc than just a release
in the sequence. This will be a Q2 release.


> >
> > Since currently the most stable platform is Windows/IA32 I suggest
> > that Harmony Q2 will be released on that specific platform
>
> Of course win32, but we also need to do the release on at least one
> flavor of linux.

Of course. But not necessarily at the same time.

Thanks,
Mikhail


>
> geir
>
> >
> > Opinions?
> >
> > Thanks,
> > Mikhail
> >
> > [1] http://harmony.apache.org/roadmap.html
>
>

Re: [general] Harmony Q2 release requirements

["Geir Magnusson Jr." <ge...@pobox.com>]

On Mar 5, 2007, at 3:53 AM, 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.

That was a long distance guess, not The Law :)

Now that we are closer, we probably need to re-assess.  For example,  
I'd much rather see a sequence of "developer releases" leading up to  
our 1.0, whenever that will be, with each dev release building on the  
last.

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

Absolutely.  I thought that is what we're doing already :)


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

Yes

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

I have no idea what that means.  We still need to continue completion  
- our goal is a compatible implementation of Java SE 5, so we need to  
continue working in that direction.

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

+1

>
> 2) running 2-3 open source server-side software
>

+1

>
> 3) running 2-3 open source developers tools

+1

>
>
> 4) setting up necessary testing infrastructure and having near 100%
> pass rates for the suites we have

Sure, and this is already in progress.

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

Again, I don't support the idea of One Big Q2 release.  I'd rather  
see us setup a sequence of developer releases making incremental  
improvement.

>
> Since currently the most stable platform is Windows/IA32 I suggest
> that Harmony Q2 will be released on that specific platform

Of course win32, but we also need to do the release on at least one  
flavor of linux.

geir

>
> Opinions?
>
> Thanks,
> Mikhail
>
> [1] http://harmony.apache.org/roadmap.html