harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Fedotov <alexei.fedo...@gmail.com>
Subject Re: [general] Lesson and roadmap thoughts
Date Mon, 20 Apr 2009 08:07:45 GMT
Hello,

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.

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.

Thanks.



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



-- 
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://www.telecom-express.ru/
http://people.apache.org/~aaf/
http://harmony.apache.org/
http://code.google.com/p/openmeetings/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message