On 11/11/2013 3:29 AM, Magnus Ihse Bursie wrote:
On 2013-11-08 19:51, Joe Darcy wrote:
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:
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.
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.
I agree. Pushing through TL will expose the patch to more testing and
will make it easier to patch it. I think you are right that this is
what we should do with this patch.
However, I'm still worried that there will be a need to manually
resolve several conflicts with changes done in the build forest in the
meantime. But I'm interpreting your answers as I should not worry
about that.
Someone will have to resolve the conflicts at some point ;-)
The situation I want to avoid is one which happened with freetype
detection recently: when a freetype detection change went from build ->
master -> TL, it broke my Linux build setup for a child of TL. The
corrected fix was in the build forest, but for some time that did me not
much good working off as a child of TL given the propagation delays of
the fix across the graph of forests.
-Joe
