Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of t.p.ellison@gmail.com
 designates 209.85.132.247 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=M47NbvSdOkIA04W1zje10SsPhhYKUYnM62RtxtgoMpOqPUhDbQwwUpZ9AXFOv/vjlJ
         o9hhrgWYbsd/CPayp4VrZ/pKi6jY+h7y/xQJSMPvslUTuuG+Ez2Z7qtuer1P3AMSGTBz
         1WIB3lcbmnP5Ja/r6AVNavRvahpFrC1gamA4s=
Message-ID: <49EC36BA.8000900@gmail.com>
Date: Mon, 20 Apr 2009 09:47:54 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [general] Lesson and roadmap thoughts
References: <49E866BE.8020909@gmail.com>
	 <fc2fc95c0904170610l274a091bj6200acbcc6d3dc85@mail.gmail.com>
	 <49E88E67.3010507@gmail.com>
 <c30d70960904200107o781a773bna800e98175b320f3@mail.gmail.com>
In-Reply-To: <c30d70960904200107o781a773bna800e98175b320f3@mail.gmail.com>
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 7bit

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