harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Qiu <sean.xx....@gmail.com>
Subject Re: [general] Lesson and roadmap thoughts
Date Tue, 21 Apr 2009 15:56:43 GMT
2009/4/20 Tim Ellison <t.p.ellison@gmail.com>:
> Alexei Fedotov wrote:
>> Under resource constraints we may even think of dropping Java 5 in favor of
>> Java 6. This would save Java 6 supporters their merge efforts and nullify
>> merge bugs.
> Maybe.  I hadn't thought of going that far - at least, not without a
> reasonable overlap period that allows people to migrate from 5.0 to 6.0
> stream.
> Given we don't make a big deal of publishing the 6.0 stream code today,
> I think it would be unreasonable to abandon the 5.0 stream abruptly.  We
> may well get to that point over time.
>> Why have not we done that before? AFAIK, one wanted to pass TCK for Java 5,
>> and that was an important step to ship Harmony release, which in turn was
>> important to officially participate in benchmarks. I don't think this plan
>> would fail due to 5% more failures we got due to Java version
>> incompatibilities. There are stronger risks, e.g. TCK absence.
> I agree, and that is why I'm proposing a different approach for the 6.0
> stream.  Rather than shoot for 100% completeness to the Java SE 6.0 API
> and request that TCK, I suggest we select a number of Harmony modules
> and publish a useful 'select' runtime.  With our architecture it is then
> trivial to expand out with the additional modules to reach the full SE
> in time.


Then from whose point of view that we should focus on?
How should we define the "selected" modules ?

Maybe we can discuss it by details to meet the goal which could and
should be customer or user oriented.

> Regards,
> Tim
>> On Fri, Apr 17, 2009 at 6:12 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>> Sian January wrote:
>>>> I agree that we need to be more timely about the next milestone.
>>>> It would also be good to focus a bit more on Java 6 since Java 5 is
>>>> starting to become old.  Maybe we could do a Java 6 M1 (or subset as
>>>> you describe) to coincide with Java 5 M10?
>>> I'm not too bothered about the 'age' of Java 5.  IMHO there are not too
>>> may apps that have a hard dependency on Java 6 APIs yet; but we have got
>>> some technology in that branch that, at the moment, does not see the
>>> light of day and that is a shame.
>>>> On another note, I would also like to see us get up to 100% pass rate
>>>> for the class library tests and then keep this going - i.e. if a
>>>> commit causes any tests to fail then it should be fixed asap or backed
>>>> out.  I think this would have helped us avoid some of the issues that
>>>> caused such a long stabilisation period for M9.
>>> Agreed.  Having build/test systems visible in the ASF infrastructure
>>> would help.  There has been some discussion about getting separable
>>> tests, but even if that does not come about we could extend Hudson to do
>>> a full build/test cycle too.
>>> I expect that we will have problems getting platform coverage from the
>>> ASF Hudson systems though.  AFAIK they are all Linux x86_64 machines.
>>> Regards,
>>> Tim
>>>> 2009/4/17 Tim Ellison <t.p.ellison@gmail.com>:
>>>>> Immediately after a release is usually the time that I'm thinking about
>>>>> lessons learned, the project road map, and future deliveries from
>>> Harmony.
>>>>> Most noticeable for me was the long stabilization period we undertook
>>>>> for M9 compared to earlier releases.  This was required, I believe,
>>>>> because of the longer open development period [1].  The lesson to take
>>>>> away from that is to ensure we keep an eye on our regular release
>>>>> schedule and keep the time boxes short enough that stable fixes get out
>>>>> to our users, and we minimize the frozen codebase period.
>>>>> Looking ahead I'd therefore expect 5.0 M10 to be released at the end
>>>>> May (6 weeks after April 8th = May 20).
>>>>> The other thing that bothers me is the lack of expose we give our Java
>>>>> branch.  While the majority of fixes we commit are applied to both
>>>>> branches, we have some good work completed in the Java 6 API branch's
>>>>> core classes that is not getting the uptake it deserves.
>>>>> The non-core Java 6 classes get very little attention at the moment.
>>>>> With Harmony's strong modular architecture we can easily construct a
>>>>> headless runtime that delivers those core classes without the missing
>>>>> functionality.
>>>>> I'd like to suggest that we experiment with the flexible components in
>>>>> Harmony to deliver a headless runtime based on the Java 6 APIs.
>>>>> Thoughts?
>>>>> [1] Depending on exactly how you count it, we were open from 17 Nov -
>>>>> Feb, which is a massive 14.5 weeks!
>>>>> Regards,
>>>>> Tim

Best Regards
Sean, Xiao Xia Qiu

View raw message