Supporting IcedTea7

[Xerxes Rånby]

2012-02-20 16:32, Andrew Hughes skrev:
>>> 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.

The main breakages and bit-rot occur when upgrading hotspot version and when applying security patches during the merge step when the new code are introduced into the main tree.
Unfortunately none of these changes gets discussed prior commit due to the simple nature that the development of the changes that cause breakage of zero happened outside the tree monitored by a zero build-bot.

I think this highlight why it are bad to have more than one source tree.
The set-up to keep code layered in several forests makes development harder and will introduce more code breakage when the forests merge.

During the past year at least the build-bot started to red-flag when a bump and break inside the main IcedTea 7 hg happened.


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


Then the delay of fixing these issues are mostly caused by developer pride. We really want to send the golden patch that puts every broken thing in order in one go.
In reality it would take too long time to create these golden patches, the best thing we can do are to send in small patches that merly fix one small part at a time incremental in small steps and repeat doing so until the introduced breakage are gone.
Tip: try encourage developers to send in half patches that solves half of the problem :)


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


I as a developer would be more happy to have one tree for all the openjdk 7 and icedtea 7 files.
Do we need to keep the icedtea 7 hg separate from the openjdk 7 hg now when all openjdk patches are in the forest?
How about pushing all the openjdk source files directly on top of the icedtea 7 hg?

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

Like I stated above most of the bit-rot breakages gets introduced by merges, a step that do not get any code reviewed coverage at all :/
I think by consolidating the source trees into one would reduce introduced breakages.

Cheers
Xerxes