----- Original Message ----- > On 21/07/16 17:29, Andrew Hughes wrote: > > When backporting changes, you find differences between e.g. 7 and 8, > > and you need this kind of data mining, from tools like hg annotate, in > > order to establish why that change exists and whether or not it needs > > to be kept. > > Yes, but I am still far from convinced that it makes sense to import a > broken port with a ton of patches on top. It's a matter of keeping > the repo reasonably clean. What is special about the list of bugs > that you provided? Why is it OK to merge the changes before that? >
I'm not talking about merging a broken port. This is not a new untested port. It's been in active use for a number of years and has accumulated bug fixes, and those fixes have a history which extends beyond the OpenJDK repositories into distro bug databases and IcedTea release notes. I agree that it makes sense to clean up some of the development commits where the result wasn't usable. The point in the history I've chosen seems to be the point where it switched from development to maintenance mode, receiving backports of fixes from 9 rather than new work, though I'm open to using a different one if Goetz thinks another is more suitable. Merging the changes before that correlates with your idea of importing a working port as one patch. The list of bugs after that retains the history of the issues that occurred after the initial port and makes it clear that those issues are resolved in the version of the port in OpenJDK. Yes, it is a matter of keeping the repo "reasonably clean", but not so clean that it is largely devoid of useful information. Hence the split I suggest. > Andrew. > > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
