On 11/08/2013 06:27 AM, Magnus Ihse Bursie wrote:
On 2013-11-08 14:46, Alan Bateman wrote:
On 08/11/2013 13:33, Magnus Ihse Bursie wrote:
I think there are both pros and cons by going through tl. As you
say, it will result in more testing. But it will also likely result
in a bunch of merge issues, since changes in the build system is
likely to continue arrive in the build forest. I have looked at the
latest round of webrevs, and most of them will require manual
merging if they are applied after the removal, typically meaning
updating paths.
So if we take this one in through tl, I assume we have to do one the
following:
* Accept that there will be potentially problematic manual merges
for the integrators.
* Block the build forest for more checkins until the big change hits
the master.
* Divert all build changes to tl after this one goes in and until it
reaches master.
* Don't integrate build in the next round of integration, just tl.
* ... or something else?
The changes going through jdk8/build is recent weeks have been
disruptive and I don't think it's a good use of integrators' time to
have to deal with that. I also wonder if there is really any need to
continue with jdk8/build, maybe it's time to just retire it.
I'm not sure I could figure out what you're suggested course of action
is. :-)
This change is likely to be disruptive to all other makefile changes,
regardless of which way it goes in. I'm not sure how to minimize the
conflicts.
If there is a problem with build changes pushed through build-dev, once
they get noticed after hitting TL, it can take a week or more for a fix
to propagate from the build forest -> master -> TL. Putting such fixes
through TL to begin with avoids the long propagation delays.
-Joe
