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] M3 milestone discussion
Date Mon, 27 Aug 2007 15:48:43 GMT
Salikh Zakirov wrote:
> Tim Ellison wrote:
>> Agreed, and the problems with getting a JCK license to certify official
>> releases have been well-documented.  We want to release a Java
>> implementation, not something that is not quite Java.
> 
> Somehow I cannot understand how the "official" status of the release
> is related to the "certification with JCK" status.

The 'official' goal of the project is to create Java SE, and the only
way to do that is to pass the corresponding JCK.

> I understand the desire of releasing certified 1.0 (or is it 5.0?)
> version, however, I cannot see why alpha or beta releases should
> not be done before JCK certification.

When we pass the JCK for 5.0 we can call the result Java SE 5.0, we
wouldn't use 1.0.

We are producing builds milestone towards that goal, but the
certification is all or nothing.

> Careful reading of Apache licensing policy [1] says that this is the
> sort of decision done by PMC.

The PMC are all on this list, though with summer vacations etc. things
are quiet.

> However, it also says that anything
> with non-released status should not be advertised outside of the mailing
> list (i.e. on the web site), and therefore, should not be packaged
> for end-users (i.e. Debian or Gentoo packages).
> 
> Thus, I understand what you are saying as "we should not yet advertise ourselves
> outside of our mailing list". This is exactly opposite of my opinion, that
> Harmony project need to start recruiting beta-testers (alpha-testers?)
> in a wider audience.

I agree that we should be recruiting further testers and early adopters.
 They are most likely to be developers on other significant Java
projects, and in fairness we have been very responsive to them.  Feel
free to try some apps and discuss the results.

> This is also in contradiction with the fact of stable builds being announced
> on the web site.

<shrug/> We have enough warnings and caveats on there.

> What I am suggesting, is 
> (1) come up with a stable versioning scheme (FWIW, M1 has happened to DRLVM twice already),

It did?

> (2) decide if the current status is alpha or beta

Alpha or beta towards what?  We cal them development snapshots which is
what they are.

> (3) release the next stable snapshot officially (following all the requirements [1])
>     with either of alpha and beta status
>     and all necessary notices about non-compatibility and non-certified status.
> (4) remove the "they are not official releases of the Apache Harmony project" notices
>     from the download page.
> (5) and finally, encourage (rather than discourage) including these alpha releases
>     to "unstable" areas of the popular Linux distributions

That's a proposal to bring into a wider forum (e.g. jcp-open@) since you
are suggesting that the ASF endorse a Java look-alike runtime.  The
ASF/Sun/JCP discussions are attempting to resolve whether we Sun will
honor their promise to provide a suitable license.

> PMC may as well disagree with this suggestion, but it would be nice to hear where exactly
> disagreement lies:

You may get more responses as people catch-up with their mail...

> (a) if Harmony project should not seek for a wider tester base?

I think we should, and we are.

> (b) if Harmony project should not encourage packaging for distributions?

again, we should and we are,

> (c) if Harmony project should not do uncertified alpha and beta releases?

we have the stable milestones for testing and early adopters.  As above,
I don't know how you would declare alpha or beta status against a set of
criteria we don't have access to at the moment.

Regards,
Tim

> [1] http://www.apache.org/dev/release.html#what 
> 
> quote from Apache Releases FAQ [1]
>> During the process of developing software and preparing a release, 
>> various packages are made available to the developer community for testing purposes.

>> Do not include any links on the project website that might encourage non-developers
>> to download and use nightly builds, snapshots, release candidates, or any other
>> similar package. The only people who are supposed to know about such packages are
>> the people following the dev list (or searching its archives) and thus aware
>> of the conditions placed on the package. If you find that the general public
>> are downloading such test packages, then remove them.
> 
> 
> 
> 

Mime
View raw message