Question about IcedTea patches

[Andrew Hughes]

----- Original Message -----
> Hi,
> 
> I have a question about IcedTea patches.
> 
> As far as I understand (please correct me if I am wrong further), some
> IcedTea7 specific changes are kept in icedtea7-forest/* mercurial
> repositories and other changes are kept as patches in icedtea7
> repository. And it was done so (besides legacy reasons) to be able to
> apply different patches for different configure switches.
> 
> Won't it be better to have all the changes (to upstream OpenJDK code and
> makefiles) in forest/* repositories?

They pretty much are.  The ones in the 2.x repositories are either for
bootstrapping (i.e. we don't want them on the final bootstrap tree) or
configure options as you suggest.  More of the later could probably
be moved to the main tree with some generalisation, though there's only
a few left now.

I've reprimanded people for trying to add more before. systemtap_gc is only
there because, before it was reworked, the systemtap patch it depended on
was dependent on SystemTap being enabled.  nss-config and pulse-soundproperties
are not so much patches as just enabling the use of additional service providers.
The latter wants to be moved to its own project really, and shouldn't be part of
IcedTea core.  rhino depends on the Rhino jar being present but we could probably
fix the patch to check for the jar in the makefiles and move it to the forest.
test_gamma is needed for PaX kernels and a better fix that can always be applied
will need some work on such a kernel.  I'm thinking of moving to one actually, so
may see some change there.  SELinux is already supported in the forest so PaX should
be really.

> 
> Changes for different configure switches may be kept as branches and
> configure script may merge selected branches with the same logic that is
> used now for applying patches. If coupling configure with DVCS is not
> desired (e.g for source releases) patch files may be created from
> selected branches on the fly (git format-patch) during the developer
> build or source release preparations.
> 
> Is this approach technically possible or there are more complications I
> miss?

I'm not sure how it helps anything.  It would just make maintenance more complicated
and require more dependencies to build (the DVCS), plus Internet access.

> 
> --
> Regards,
> Alex Kasko
> 

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