harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [general] Lesson and roadmap thoughts
Date Mon, 20 Apr 2009 08:47:54 GMT
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.

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 of
>>>> May (6 weeks after April 8th = May 20).
>>>>
>>>>
>>>> The other thing that bothers me is the lack of expose we give our Java 6
>>>> 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 - 27
>>>> Feb, which is a massive 14.5 weeks!
>>>>
>>>> Regards,
>>>> Tim
>>>>
>>>
>>>
> 
> 
> 

Mime
View raw message