Supporting IcedTea7

[Andrew Haley]

On 02/20/2012 03:32 PM, Andrew Hughes wrote:
>>> Besides, this discussion is about *source* releases, while the JCK
>>> only applies to binaries.  We've never made it a requirement that
>>> IcedTea source releases have a JCK-passing binary and some distros
>>> have never even run the 6 JCK, so I don't see how it's relevant to
>>> where we focus the majority of IcedTea development.
>>
>> It's crucial, IMO: it's the only way to find out if a release is
>> compatible.  It's important not to confuse testing with certification.
>> Only a binary can be certified, but a release can be tested; of
>> course
>> it has to be built first.
> 
> I'm not confusing the two but you can't make passing a test suite a
> requirement if not everyone has access to it and can openly discuss
> it.  When the JCK is available as FOSS, I'm sure we can happily
> reconsider this.

We, the IcedTea maintainers, don't get to decide if it's a requirement
for the users.  I said

"It can never be a primary release for many users until OpenJDK users
and packagers have some way of doing compatibility testing."

This is not our decision.

>>>> Secondly, while this policy makes sense in the abstract, it does
>>>> not make sense to apply it rigidly.  Zero still doesn't fully
>>>> work in OpenJDK 7, so it makes no sense for it to be the primary
>>>> platform for Zero development.
>>>
>>> This is exactly why more work needs to be going on in the 7 tree,
>>> not less.  How does concentrating on 6 help this at all?
>>
>> It doesn't.
> 
> So why not require that patches go to 7 then 6?  That's all that's
> being suggested.  Of course, if a patch is applicable only to 6, it
> doesn't apply.  I would have thought that was obvious enough not to
> warrant explicit mention.

Good.

>>> One of the main reasons I raised this issue is because we've just
>>> shipped a new 7 release that has seen little work from anyone other
>>> than myself, and with Zero and Shark builds broken.  This doesn't
>>> look good.  Unlike the ARM port, Zero& Shark DID work and have been
>>> allowed to bitrot, as Oracle have continued development on HotSpot
>>> and we haven't.
>>
>> Firstly, it's wholly false to say that Zero& Shark have been
>> allowed to bitrot.  People have been working on them, and trying to
>> solve some very difficult problems.  It's a calumny against our
>> developers to suggest that they have been negligent, because it's
>> simply untrue.  The problems are very difficult to solve.
> 
> A bad choice of words I guess, but the fact is that it HAS bitrotted
> i.e. it did build and now it doesn't.  There also has been very
> little evidence of anyone working on it, so if I've been giving the
> impression of negligence, it's because of the sheer lack of
> communication as to what is being done about this.
> 
> There are patches that at least get Zero building again and which
> thus allows people to at least test it.  I believe these have been
> available for a while, but yet no-one thought to commit them until
> after the release:

I think people may have taken the view that without invokedynamic
there wasn't much point.  However, there is scope for a point release
on the branch to fix this.

> I don't see any review or posting of this patch on the mailing lists either,

I reviewed it.

>> Patch review is good.  Process for process' sake isn't.  Slavishly
>> following rules when it doesn't make sense isn't.  For example, it
>> wouldn't make any sense to hold back a patch to fix a broken build.
> 
> I agree.  I would regard that as trivial.

That's useful to know.  Not everyone would, and some aren't trivial.
the patch above isn't really trivial, IMO.  But it is an improvement
and even though we could argue about it forever it's better than
not having it.

>>> I don't see how the policy is different from that of, say, gcc.
>>
>> It is a little bit.  For example, each gcc component has
>> maintainers who are competent to review patches and can commit to
>> their own areas, and it has global maintainers who can commit to
>> everything.  But gcc is a larger and more hierarchical
>> organization, so it's not exactly comparable.
> 
> That's never been a side of gcc development I've been keen on, and I
> don't think it's one we need to emulate, given our smaller scale.

Oh dear.  :-)

> If there is no-one capable of reviewing an ARM or Zero patch, I
> think that highlights a problem with our set of active developers
> rather than one with the process itself.  

Well, yes, but have to play the hand that we're given.

> Everyone makes mistakes and reviews can help catch these.

>>> We allow trivial fixes through and, in fact, are less restrictive
>>> in allowing unreviewed commits to HEAD.  We can certainly have
>>> exceptions for areas like ARM and Zero *code* but I do think all
>>> changes to the build (OpenJDK& IcedTea) should be reviewed.
>>
>> Fair enough, with the caveats above.
> 
> The Zero patch linked above did mix the two, which I'm not keen on.
> The Makefile changes are trivial and obvious enough in that case,
> but such changes should really be at least sanity checked by another
> developer.

Indeed.

>>> Our release branches require review and this has generally not
>>> stopped people committing to them.  So I don't see immediately why
>>> this would be the issue with 7.  From my observation of discussion
>>> on IRC, it seems most people haven't even tried BUILDING it, never
>>> mind getting to the point of committing patches.
>>>
>>> I'll write a formal proposal and we'll vote on this policy switch
>>> using the same simple majority policy as OpenJDK:
>>> http://openjdk.java.net/bylaws#_3
>>
>> I don't think injecting more process at this sage makes any sense at
>> all.  It makes far more sense to *discuss* this and try to find a
>> consensus.  I don't feel we're very far away from one, so why try to
>> call a vote already?
> 
> Perhaps I was a little over-keen.  I suggested it mainly because
> there has been cries of unfairness in making such decisions in the
> past, but I'm happier to go with a simpler more laidback approach to
> this.
> 
> From your reply above, it actually sounds to me like we can all
> agree on requiring patches for everything applicable to 7 go to 7
> first, then 6.

Within reason, maybe.  But we are potentially increasing the amount of
work people have to do, and double commits are a PITA for everyone.
As a rule of thumb it's OK, but I hope very much not to see it used to
harangue people for not doing their work "properly".  Let's see how
it goes.

Andrew.