Supporting IcedTea7

[Andrew Hughes]

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

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

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

http://icedtea.classpath.org/hg/icedtea7-forest/hotspot/rev/433e4570d57c

I have no idea as to whether these have also gone upstream as well.  Anyone?

I don't see the value in making releases with known bugs that have been fixed,
but where the solutions are hidden away somewhere and not in the public
repositories.

I don't see any review or posting of this patch on the mailing lists either,
so I don't see how that was a blocker for it being added.

> > It doesn't make sense for development to keep focusing on the dead
> > end that is OpenJDK6.  Even 7 is only a halfway house; to properly
> > work within the OpenJDK community, development should be on 8
> > first,
> > then backported to 7& 6.  This is where Oracle are working and it
> > doesn't make sense for us to focus all our efforts on a release
> > that
> > should really just be seeing security fixes and backports now.
> 
> True enough.
> 
> >> Lastly, the "CommitPolicy" page attempts to impose more rigid
> >> policies for IcedTea7 HEAD / forest post 2.0.  While proper patch
> >> review is undoubtedly a good thing, there are cases where it is
> >> inappropriate.  In some areas, for example, the committer is the
> >> only person who really understands the code.  In other cases it's
> >> obvious what needs to be done, and the process serves no purpose.
> >> I suspect that this is one reason why our support for IcedTea7 may
> >> be lacking.
> >>
> >> So, while this policy makes some sense, let's use it as a guide
> >> rather than a straitjacket.
> >>
> >
> > If this is an issue, we can discuss it as a group and change
> > things.
> > I wasn't aware it was until you raised it here.  Although the page
> > says that about 2.0 on, it's generally not been enforced so far.
> 
> I'm avoiding the possibility that moving to 2.0 might mean that the
> rules might be changed without anyone noticing.  Assuming that they
> read this!  :-)

I don't see why that would be the case.  We can't make people read their
e-mail.  They only have themselves to blame if they don't.  The archives
for this list are public.

> 
> > I'm a little confused as to your position on this.  You've seemed
> > to
> > say in previous e-mails that patches should be reviewed on entry to
> > HEAD (which is what this 2.0 change would bring about) rather than
> > on going into review branches.  You seem to be saying the opposite
> > here.  Which is 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.

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

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

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

> 
> Andrew.
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07