Could we officially designate some mercurial write-mostly forest as a
suitable submission for risky changes to be submitted to?
An integrator (Tim or Erik?) would take ownership of the forest (i.e.
periodically sync, build, test) and any changes that broke the build would
be simply 'hg strip'ed out
On 04/11/13 14:40, Brad Wetmore wrote:
Three of your builds (macos_x64/windows_i586/windows_x64) failed (1
failed in install:unix-wrappers and 2 due to missing docs because of
c:/ resolution), but there were no problems with building the JDK.
Since this is the old build, I think we're ok to pu
Three of your builds (macos_x64/windows_i586/windows_x64) failed (1
failed in install:unix-wrappers and 2 due to missing docs because of c:/
resolution), but there were no problems with building the JDK. Since
this is the old build, I think we're ok to putback.
Your change looks good to me, I
On 4/11/2013 3:45 AM, Alan Bateman wrote:
Personally I think it would be good to agree and set a date, after which
there is no requirement to keep the old build "working". At the moment
it is a tax on all changes that involve change changes. I'm not even
sure that the old build generates good
On 4/11/13 1:52 AM, David Katleman wrote:
> Thank you Tim!
>
> Any other comments before I commit?
Nothing from me - You'll need to send a request for approval to jdk7u-dev
before the push,
though.
cheers,
dalibor topic
>
> Thanks
> Dave
>
> On 4/10/2013 1:51 PM, Tim Bell wrote:
Erik,
Would you like me to look at this?
-- Jon
On 04/11/2013 10:56 AM, Naoto Sato wrote:
Hello,
Is anyone looking into this issue (on the jbs, noone is assigned)?
This has been biting me as well on Windows builds quite a while.
Naoto
On 4/8/13 7:11 AM, Alexander Scherbatiy wrote:
On 4/8
Hello,
Is anyone looking into this issue (on the jbs, noone is assigned)? This
has been biting me as well on Windows builds quite a while.
Naoto
On 4/8/13 7:11 AM, Alexander Scherbatiy wrote:
On 4/8/2013 5:21 PM, Erik Joelsson wrote:
On 2013-04-08 15:17, Anthony Petrov wrote:
Thanks for
On Apr 11 2013, at 03:53 , Erik Joelsson wrote:
> Open part of this review.
>
> The licensee bundles aren't buildable with the new build for several reasons.
> I've tried to fix all the issues that I've found and have now
> successfully built them on linux, windows and solaris. Here is a list o
Andrew,
I agree that any change would have to be tested on a variety of
platforms. Historically, the limit used to be 512m, but has crept up
over recent times. My investigations have been to understand
why we have been forced to increase this number; as a result
we found out that a memory leak
Good catch Tim!
I took a good look and came up with this:
http://cr.openjdk.java.net/~erikj/8011812/webrev.jdk.02/
Removing the redundant macosx case and adding the -I parameter for all
platforms. I have a jprt job in Stockholm verifying this patch, so far
looking good. Brad, feel free to pus
Open part of this review.
The licensee bundles aren't buildable with the new build for several
reasons. I've tried to fix all the issues that I've found and have now
successfully built them on linux, windows and solaris. Here is a list of
the changes that I had to do to OpenJDK:
* Filter out
On 11/04/2013 11:24, Andrew Hughes wrote:
- Original Message -
On 09/04/2013 23:11, Omair Majid wrote:
:
I would like to avoid this in the future; any tips on how to run the old
build? I couldn't get it to work last I tried (the error messages were
redirecting me to the new build).
I s
- Original Message -
> Build folk,
>
> As a result of these two changesets now in tl/langtools, we can now
> reduce the memory requirements for javadoc in
> (root)common/makefiles/javadoc/Javadoc.gmk.
>
> changeset: 1678:3f3cc8d3f13c
> tag: tip
> user:jjg
> date:
- Original Message -
> On 09/04/2013 23:11, Omair Majid wrote:
> > :
> > I would like to avoid this in the future; any tips on how to run the old
> > build? I couldn't get it to work last I tried (the error messages were
> > redirecting me to the new build).
> I see Brad's reply but I think
Hi all,
We're looking to help alleviate these sorts of issues with the Betterrev
project. Basically patches will get build against common platforms/forests
and results sent back to the submitter and the appropriate OpenJDK mailing
list.
We still have some way to go, but early work is looking pro
15 matches
Mail list logo
