You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2007/04/26 11:18:34 UTC
[snapshot] Freezing the code for Milestone build?
To ensure we get a stable build we need to freeze the code for a short
duration, which will allow us to:
- produce the set of milestone candidates,
i.e. a full rebuild on Windows, Linux (with libstdc++ v5 dependency)
and Linux (with libstdc++ v6 dependency) in JRE, JDK, and HDK
formats. At this point we will still only publish x86 snapshots.
- test the snapshots,
i.e. test installs (it would be good if you have a machine without
your usual development environment set up to ensure we don't have
dependencies on dev tools); and testing various applications to check
they work as well as we would expect for this snapshot.
While we do this it is helpful if the codebase is not being changed. It
sounds like people are happy enough to freeze HEAD rather than create a
branch, so let's do that.
During the freeze there should be no commits unless we agree here on the
dev list that there is a problem serious enough for us to re-spin a new
candidate. I would hope that producing the snapshots and some focused
testing can happen over one or two days (max) to declare the build good.
Once the milestone is declared good we will reopen for development as
usual.
Does that sound like a reasonable procedure? Did I miss anything out?
so:
- when do we freeze (today/tomorrow)? any outstanding MUST fix's?
- volunteers with machines for producing the candidates?
Regards,
Tim
Re: [snapshot] Freezing the code for Milestone build?
Posted by Alexey Varlamov <al...@gmail.com>.
2007/4/26, Alexey Petrenko <al...@gmail.com>:
> CC reports no failures for x86 now.
This is intermittent failure...
>
> 2007/4/26, Alexey Petrenko <al...@gmail.com>:
> > It looks like I've missed drlvm-test failure on Windows/x86. Are
> > somebody from VM gurus looking into?
> >
> > SY, Alexey
> >
> > 2007/4/26, Alexey Petrenko <al...@gmail.com>:
> > > Now means now. I see number success alerts from CC and all the x86 CCs
> > > looks up on the mentioned page.
> > >
> > > Did I miss something?
> > >
> > > SY, Alexey
> > >
> > > 2007/4/26, Mikhail Loenko <ml...@gmail.com>:
> > > > 2007/4/26, Alexey Petrenko <al...@gmail.com>:
> > > > > Looks like all the CCs are up now. Is that correct?
> > > >
> > > > the 'now' is last time you pressed 'refresh' :)
> > > > what does 'now' mean in your case?
> > > >
> > > > Thanks,
> > > > Mikhail
> > > >
> > > > >
> > > > > SY, Alexey
> > > > >
> > > > > 2007/4/26, Mikhail Loenko <ml...@gmail.com>:
> > > > > > We should freeze when all CCs are in the up state [1]
> > > > > >
> > > > > > Can we use the snapshots [2]? My understanding is that the snapshots
> > > > > > are updated in the "all CCs up" moments, so probably almost-a-week old
> > > > > > snapshots are the best for the Milestone.
> > > > > >
> > > > > > Were there any significant changes since that? I know about gc switch,
> > > > > > but not sure how it affected stability...
> > > > > >
> > > > > > Thanks,
> > > > > > Mikhail
> > > > > >
> > > > > > [1] http://www.harmonytest.org/upload/cc1.html
> > > > > > [2] http://people.apache.org/builds/harmony/snapshots/
> > > > > >
> > > > > > 2007/4/26, Tim Ellison <t....@gmail.com>:
> > > > > > > To ensure we get a stable build we need to freeze the code for a short
> > > > > > > duration, which will allow us to:
> > > > > > >
> > > > > > > - produce the set of milestone candidates,
> > > > > > > i.e. a full rebuild on Windows, Linux (with libstdc++ v5 dependency)
> > > > > > > and Linux (with libstdc++ v6 dependency) in JRE, JDK, and HDK
> > > > > > > formats. At this point we will still only publish x86 snapshots.
> > > > > > >
> > > > > > > - test the snapshots,
> > > > > > > i.e. test installs (it would be good if you have a machine without
> > > > > > > your usual development environment set up to ensure we don't have
> > > > > > > dependencies on dev tools); and testing various applications to check
> > > > > > > they work as well as we would expect for this snapshot.
> > > > > > >
> > > > > > > While we do this it is helpful if the codebase is not being changed. It
> > > > > > > sounds like people are happy enough to freeze HEAD rather than create a
> > > > > > > branch, so let's do that.
> > > > > > >
> > > > > > > During the freeze there should be no commits unless we agree here on the
> > > > > > > dev list that there is a problem serious enough for us to re-spin a new
> > > > > > > candidate. I would hope that producing the snapshots and some focused
> > > > > > > testing can happen over one or two days (max) to declare the build good.
> > > > > > > Once the milestone is declared good we will reopen for development as
> > > > > > > usual.
> > > > > > >
> > > > > > > Does that sound like a reasonable procedure? Did I miss anything out?
> > > > > > >
> > > > > > > so:
> > > > > > > - when do we freeze (today/tomorrow)? any outstanding MUST fix's?
> > > > > > > - volunteers with machines for producing the candidates?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Tim
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [snapshot] Freezing the code for Milestone build?
Posted by Alexey Petrenko <al...@gmail.com>.
CC reports no failures for x86 now.
2007/4/26, Alexey Petrenko <al...@gmail.com>:
> It looks like I've missed drlvm-test failure on Windows/x86. Are
> somebody from VM gurus looking into?
>
> SY, Alexey
>
> 2007/4/26, Alexey Petrenko <al...@gmail.com>:
> > Now means now. I see number success alerts from CC and all the x86 CCs
> > looks up on the mentioned page.
> >
> > Did I miss something?
> >
> > SY, Alexey
> >
> > 2007/4/26, Mikhail Loenko <ml...@gmail.com>:
> > > 2007/4/26, Alexey Petrenko <al...@gmail.com>:
> > > > Looks like all the CCs are up now. Is that correct?
> > >
> > > the 'now' is last time you pressed 'refresh' :)
> > > what does 'now' mean in your case?
> > >
> > > Thanks,
> > > Mikhail
> > >
> > > >
> > > > SY, Alexey
> > > >
> > > > 2007/4/26, Mikhail Loenko <ml...@gmail.com>:
> > > > > We should freeze when all CCs are in the up state [1]
> > > > >
> > > > > Can we use the snapshots [2]? My understanding is that the snapshots
> > > > > are updated in the "all CCs up" moments, so probably almost-a-week old
> > > > > snapshots are the best for the Milestone.
> > > > >
> > > > > Were there any significant changes since that? I know about gc switch,
> > > > > but not sure how it affected stability...
> > > > >
> > > > > Thanks,
> > > > > Mikhail
> > > > >
> > > > > [1] http://www.harmonytest.org/upload/cc1.html
> > > > > [2] http://people.apache.org/builds/harmony/snapshots/
> > > > >
> > > > > 2007/4/26, Tim Ellison <t....@gmail.com>:
> > > > > > To ensure we get a stable build we need to freeze the code for a short
> > > > > > duration, which will allow us to:
> > > > > >
> > > > > > - produce the set of milestone candidates,
> > > > > > i.e. a full rebuild on Windows, Linux (with libstdc++ v5 dependency)
> > > > > > and Linux (with libstdc++ v6 dependency) in JRE, JDK, and HDK
> > > > > > formats. At this point we will still only publish x86 snapshots.
> > > > > >
> > > > > > - test the snapshots,
> > > > > > i.e. test installs (it would be good if you have a machine without
> > > > > > your usual development environment set up to ensure we don't have
> > > > > > dependencies on dev tools); and testing various applications to check
> > > > > > they work as well as we would expect for this snapshot.
> > > > > >
> > > > > > While we do this it is helpful if the codebase is not being changed. It
> > > > > > sounds like people are happy enough to freeze HEAD rather than create a
> > > > > > branch, so let's do that.
> > > > > >
> > > > > > During the freeze there should be no commits unless we agree here on the
> > > > > > dev list that there is a problem serious enough for us to re-spin a new
> > > > > > candidate. I would hope that producing the snapshots and some focused
> > > > > > testing can happen over one or two days (max) to declare the build good.
> > > > > > Once the milestone is declared good we will reopen for development as
> > > > > > usual.
> > > > > >
> > > > > > Does that sound like a reasonable procedure? Did I miss anything out?
> > > > > >
> > > > > > so:
> > > > > > - when do we freeze (today/tomorrow)? any outstanding MUST fix's?
> > > > > > - volunteers with machines for producing the candidates?
> > > > > >
> > > > > > Regards,
> > > > > > Tim
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [snapshot] Freezing the code for Milestone build?
Posted by Alexey Petrenko <al...@gmail.com>.
It looks like I've missed drlvm-test failure on Windows/x86. Are
somebody from VM gurus looking into?
SY, Alexey
2007/4/26, Alexey Petrenko <al...@gmail.com>:
> Now means now. I see number success alerts from CC and all the x86 CCs
> looks up on the mentioned page.
>
> Did I miss something?
>
> SY, Alexey
>
> 2007/4/26, Mikhail Loenko <ml...@gmail.com>:
> > 2007/4/26, Alexey Petrenko <al...@gmail.com>:
> > > Looks like all the CCs are up now. Is that correct?
> >
> > the 'now' is last time you pressed 'refresh' :)
> > what does 'now' mean in your case?
> >
> > Thanks,
> > Mikhail
> >
> > >
> > > SY, Alexey
> > >
> > > 2007/4/26, Mikhail Loenko <ml...@gmail.com>:
> > > > We should freeze when all CCs are in the up state [1]
> > > >
> > > > Can we use the snapshots [2]? My understanding is that the snapshots
> > > > are updated in the "all CCs up" moments, so probably almost-a-week old
> > > > snapshots are the best for the Milestone.
> > > >
> > > > Were there any significant changes since that? I know about gc switch,
> > > > but not sure how it affected stability...
> > > >
> > > > Thanks,
> > > > Mikhail
> > > >
> > > > [1] http://www.harmonytest.org/upload/cc1.html
> > > > [2] http://people.apache.org/builds/harmony/snapshots/
> > > >
> > > > 2007/4/26, Tim Ellison <t....@gmail.com>:
> > > > > To ensure we get a stable build we need to freeze the code for a short
> > > > > duration, which will allow us to:
> > > > >
> > > > > - produce the set of milestone candidates,
> > > > > i.e. a full rebuild on Windows, Linux (with libstdc++ v5 dependency)
> > > > > and Linux (with libstdc++ v6 dependency) in JRE, JDK, and HDK
> > > > > formats. At this point we will still only publish x86 snapshots.
> > > > >
> > > > > - test the snapshots,
> > > > > i.e. test installs (it would be good if you have a machine without
> > > > > your usual development environment set up to ensure we don't have
> > > > > dependencies on dev tools); and testing various applications to check
> > > > > they work as well as we would expect for this snapshot.
> > > > >
> > > > > While we do this it is helpful if the codebase is not being changed. It
> > > > > sounds like people are happy enough to freeze HEAD rather than create a
> > > > > branch, so let's do that.
> > > > >
> > > > > During the freeze there should be no commits unless we agree here on the
> > > > > dev list that there is a problem serious enough for us to re-spin a new
> > > > > candidate. I would hope that producing the snapshots and some focused
> > > > > testing can happen over one or two days (max) to declare the build good.
> > > > > Once the milestone is declared good we will reopen for development as
> > > > > usual.
> > > > >
> > > > > Does that sound like a reasonable procedure? Did I miss anything out?
> > > > >
> > > > > so:
> > > > > - when do we freeze (today/tomorrow)? any outstanding MUST fix's?
> > > > > - volunteers with machines for producing the candidates?
> > > > >
> > > > > Regards,
> > > > > Tim
> > > > >
> > > >
> > >
> >
>
Re: [snapshot] Freezing the code for Milestone build?
Posted by Alexey Petrenko <al...@gmail.com>.
Now means now. I see number success alerts from CC and all the x86 CCs
looks up on the mentioned page.
Did I miss something?
SY, Alexey
2007/4/26, Mikhail Loenko <ml...@gmail.com>:
> 2007/4/26, Alexey Petrenko <al...@gmail.com>:
> > Looks like all the CCs are up now. Is that correct?
>
> the 'now' is last time you pressed 'refresh' :)
> what does 'now' mean in your case?
>
> Thanks,
> Mikhail
>
> >
> > SY, Alexey
> >
> > 2007/4/26, Mikhail Loenko <ml...@gmail.com>:
> > > We should freeze when all CCs are in the up state [1]
> > >
> > > Can we use the snapshots [2]? My understanding is that the snapshots
> > > are updated in the "all CCs up" moments, so probably almost-a-week old
> > > snapshots are the best for the Milestone.
> > >
> > > Were there any significant changes since that? I know about gc switch,
> > > but not sure how it affected stability...
> > >
> > > Thanks,
> > > Mikhail
> > >
> > > [1] http://www.harmonytest.org/upload/cc1.html
> > > [2] http://people.apache.org/builds/harmony/snapshots/
> > >
> > > 2007/4/26, Tim Ellison <t....@gmail.com>:
> > > > To ensure we get a stable build we need to freeze the code for a short
> > > > duration, which will allow us to:
> > > >
> > > > - produce the set of milestone candidates,
> > > > i.e. a full rebuild on Windows, Linux (with libstdc++ v5 dependency)
> > > > and Linux (with libstdc++ v6 dependency) in JRE, JDK, and HDK
> > > > formats. At this point we will still only publish x86 snapshots.
> > > >
> > > > - test the snapshots,
> > > > i.e. test installs (it would be good if you have a machine without
> > > > your usual development environment set up to ensure we don't have
> > > > dependencies on dev tools); and testing various applications to check
> > > > they work as well as we would expect for this snapshot.
> > > >
> > > > While we do this it is helpful if the codebase is not being changed. It
> > > > sounds like people are happy enough to freeze HEAD rather than create a
> > > > branch, so let's do that.
> > > >
> > > > During the freeze there should be no commits unless we agree here on the
> > > > dev list that there is a problem serious enough for us to re-spin a new
> > > > candidate. I would hope that producing the snapshots and some focused
> > > > testing can happen over one or two days (max) to declare the build good.
> > > > Once the milestone is declared good we will reopen for development as
> > > > usual.
> > > >
> > > > Does that sound like a reasonable procedure? Did I miss anything out?
> > > >
> > > > so:
> > > > - when do we freeze (today/tomorrow)? any outstanding MUST fix's?
> > > > - volunteers with machines for producing the candidates?
> > > >
> > > > Regards,
> > > > Tim
> > > >
> > >
> >
>
Re: [snapshot] Freezing the code for Milestone build?
Posted by Vladimir Ivanov <iv...@gmail.com>.
Current CC/CI status (now, April 26, 17:00 NSK):
Linux'es are OK.
we have intermittently failed test on Windows XP:
------------------ execution log ------------------------------
error: testGetAllStackTraces java.lang.ThreadTest
Unit Test Error Details: (1)
Test: testGetAllStackTracesClass: java.lang.ThreadTest
java.util.NoSuchElementException
at java.util.WeakHashMap$HashIterator.next(WeakHashMap.java:162)
at java.util.AbstractCollection.toArray(AbstractCollection.java)
at java.lang.ThreadGroup.copyThreads(ThreadGroup.java)
at java.lang.ThreadGroup.enumerate(ThreadGroup.java:456)
at java.lang.ThreadGroup.enumerate(ThreadGroup.java:472)
at java.lang.ThreadGroup.enumerate(ThreadGroup.java:472)
at java.lang.ThreadGroup.enumerate(ThreadGroup.java:202)
at java.lang.Thread.getAllStackTraces(Thread.java)
at java.lang.ThreadTest.testGetAllStackTraces(ThreadTest.java:1011)
at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
at java.lang.reflect.Method.invoke(Method.java:382)
at junit.framework.TestCase.runTest(TestCase.java:164)
at junit.framework.TestCase.runBare(TestCase.java)
at junit.framework.TestResult$1.protect(TestResult.java)
at junit.framework.TestResult.runProtected(TestResult.java)
at junit.framework.TestResult.run(TestResult.java)
at junit.framework.TestCase.run(TestCase.java)
at junit.framework.TestSuite.runTest(TestSuite.java)
at junit.framework.TestSuite.run(TestSuite.java)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:546)
--------------------------------------------------------------------
Windows x86_64:
we have intermittently failed tests:
gc.LOS_jet
gc.MultiThreads_jet
gc.Mark_opt
thanks, Vladimir
On 4/26/07, Mikhail Loenko <ml...@gmail.com> wrote:
> 2007/4/26, Alexey Petrenko <al...@gmail.com>:
> > Looks like all the CCs are up now. Is that correct?
>
> the 'now' is last time you pressed 'refresh' :)
> what does 'now' mean in your case?
>
> Thanks,
> Mikhail
>
> >
> > SY, Alexey
> >
> > 2007/4/26, Mikhail Loenko <ml...@gmail.com>:
> > > We should freeze when all CCs are in the up state [1]
> > >
> > > Can we use the snapshots [2]? My understanding is that the snapshots
> > > are updated in the "all CCs up" moments, so probably almost-a-week old
> > > snapshots are the best for the Milestone.
> > >
> > > Were there any significant changes since that? I know about gc switch,
> > > but not sure how it affected stability...
> > >
> > > Thanks,
> > > Mikhail
> > >
> > > [1] http://www.harmonytest.org/upload/cc1.html
> > > [2] http://people.apache.org/builds/harmony/snapshots/
> > >
> > > 2007/4/26, Tim Ellison <t....@gmail.com>:
> > > > To ensure we get a stable build we need to freeze the code for a short
> > > > duration, which will allow us to:
> > > >
> > > > - produce the set of milestone candidates,
> > > > i.e. a full rebuild on Windows, Linux (with libstdc++ v5 dependency)
> > > > and Linux (with libstdc++ v6 dependency) in JRE, JDK, and HDK
> > > > formats. At this point we will still only publish x86 snapshots.
> > > >
> > > > - test the snapshots,
> > > > i.e. test installs (it would be good if you have a machine without
> > > > your usual development environment set up to ensure we don't have
> > > > dependencies on dev tools); and testing various applications to check
> > > > they work as well as we would expect for this snapshot.
> > > >
> > > > While we do this it is helpful if the codebase is not being changed. It
> > > > sounds like people are happy enough to freeze HEAD rather than create a
> > > > branch, so let's do that.
> > > >
> > > > During the freeze there should be no commits unless we agree here on the
> > > > dev list that there is a problem serious enough for us to re-spin a new
> > > > candidate. I would hope that producing the snapshots and some focused
> > > > testing can happen over one or two days (max) to declare the build good.
> > > > Once the milestone is declared good we will reopen for development as
> > > > usual.
> > > >
> > > > Does that sound like a reasonable procedure? Did I miss anything out?
> > > >
> > > > so:
> > > > - when do we freeze (today/tomorrow)? any outstanding MUST fix's?
> > > > - volunteers with machines for producing the candidates?
> > > >
> > > > Regards,
> > > > Tim
> > > >
> > >
> >
>
Re: [snapshot] Freezing the code for Milestone build?
Posted by Mikhail Loenko <ml...@gmail.com>.
2007/4/26, Alexey Petrenko <al...@gmail.com>:
> Looks like all the CCs are up now. Is that correct?
the 'now' is last time you pressed 'refresh' :)
what does 'now' mean in your case?
Thanks,
Mikhail
>
> SY, Alexey
>
> 2007/4/26, Mikhail Loenko <ml...@gmail.com>:
> > We should freeze when all CCs are in the up state [1]
> >
> > Can we use the snapshots [2]? My understanding is that the snapshots
> > are updated in the "all CCs up" moments, so probably almost-a-week old
> > snapshots are the best for the Milestone.
> >
> > Were there any significant changes since that? I know about gc switch,
> > but not sure how it affected stability...
> >
> > Thanks,
> > Mikhail
> >
> > [1] http://www.harmonytest.org/upload/cc1.html
> > [2] http://people.apache.org/builds/harmony/snapshots/
> >
> > 2007/4/26, Tim Ellison <t....@gmail.com>:
> > > To ensure we get a stable build we need to freeze the code for a short
> > > duration, which will allow us to:
> > >
> > > - produce the set of milestone candidates,
> > > i.e. a full rebuild on Windows, Linux (with libstdc++ v5 dependency)
> > > and Linux (with libstdc++ v6 dependency) in JRE, JDK, and HDK
> > > formats. At this point we will still only publish x86 snapshots.
> > >
> > > - test the snapshots,
> > > i.e. test installs (it would be good if you have a machine without
> > > your usual development environment set up to ensure we don't have
> > > dependencies on dev tools); and testing various applications to check
> > > they work as well as we would expect for this snapshot.
> > >
> > > While we do this it is helpful if the codebase is not being changed. It
> > > sounds like people are happy enough to freeze HEAD rather than create a
> > > branch, so let's do that.
> > >
> > > During the freeze there should be no commits unless we agree here on the
> > > dev list that there is a problem serious enough for us to re-spin a new
> > > candidate. I would hope that producing the snapshots and some focused
> > > testing can happen over one or two days (max) to declare the build good.
> > > Once the milestone is declared good we will reopen for development as
> > > usual.
> > >
> > > Does that sound like a reasonable procedure? Did I miss anything out?
> > >
> > > so:
> > > - when do we freeze (today/tomorrow)? any outstanding MUST fix's?
> > > - volunteers with machines for producing the candidates?
> > >
> > > Regards,
> > > Tim
> > >
> >
>
Re: [snapshot] Freezing the code for Milestone build?
Posted by Alexey Petrenko <al...@gmail.com>.
Looks like all the CCs are up now. Is that correct?
SY, Alexey
2007/4/26, Mikhail Loenko <ml...@gmail.com>:
> We should freeze when all CCs are in the up state [1]
>
> Can we use the snapshots [2]? My understanding is that the snapshots
> are updated in the "all CCs up" moments, so probably almost-a-week old
> snapshots are the best for the Milestone.
>
> Were there any significant changes since that? I know about gc switch,
> but not sure how it affected stability...
>
> Thanks,
> Mikhail
>
> [1] http://www.harmonytest.org/upload/cc1.html
> [2] http://people.apache.org/builds/harmony/snapshots/
>
> 2007/4/26, Tim Ellison <t....@gmail.com>:
> > To ensure we get a stable build we need to freeze the code for a short
> > duration, which will allow us to:
> >
> > - produce the set of milestone candidates,
> > i.e. a full rebuild on Windows, Linux (with libstdc++ v5 dependency)
> > and Linux (with libstdc++ v6 dependency) in JRE, JDK, and HDK
> > formats. At this point we will still only publish x86 snapshots.
> >
> > - test the snapshots,
> > i.e. test installs (it would be good if you have a machine without
> > your usual development environment set up to ensure we don't have
> > dependencies on dev tools); and testing various applications to check
> > they work as well as we would expect for this snapshot.
> >
> > While we do this it is helpful if the codebase is not being changed. It
> > sounds like people are happy enough to freeze HEAD rather than create a
> > branch, so let's do that.
> >
> > During the freeze there should be no commits unless we agree here on the
> > dev list that there is a problem serious enough for us to re-spin a new
> > candidate. I would hope that producing the snapshots and some focused
> > testing can happen over one or two days (max) to declare the build good.
> > Once the milestone is declared good we will reopen for development as
> > usual.
> >
> > Does that sound like a reasonable procedure? Did I miss anything out?
> >
> > so:
> > - when do we freeze (today/tomorrow)? any outstanding MUST fix's?
> > - volunteers with machines for producing the candidates?
> >
> > Regards,
> > Tim
> >
>
Re: [snapshot] Freezing the code for Milestone build?
Posted by Tim Ellison <t....@gmail.com>.
Stepan Mishura wrote:
> OK, I'm going to add 'release candidate' paragraph with links to
> milestone candidates.
Thanks. It might be more logical to reverse the order of the sections
on the download page, so we have:
Releases
none
Milestone Builds
M1
Snapshot Builds
Latest
with an appropriate description of what each type of build offers. Not
sure why, but it seems more logical that way round to me <g>.
Regards,
Tim
Re: [snapshot] Freezing the code for Milestone build?
Posted by Tim Ellison <t....@gmail.com>.
Stepan Mishura wrote:
> Thanks for the reminding about awt libraries - I forgot about them. My
> understanding that we can configure compiler to use required library
> via LD_LIBRARY_PATH. Say
> $export LD_LIBRARY_PATH=/mydir:$LD_LIBRARY_PATH
> $ls -l /mydir
> libstdc++.so -> required lib
> libstdc++.a -> required archive
>
> I think also it might be necessary to build awt libraries (jpeg, lcms
> and png) with required libstdc++.so and place them to
> classlib/depends/libs/build dir.
Now you know why packaging projects exist :-) Good luck.
Regards,
Tim
Re: [snapshot] Freezing the code for Milestone build?
Posted by Stepan Mishura <st...@gmail.com>.
On 4/27/07, Mark Hindess wrote:
<SNIP>
> > > Agreed, and thanks for volunteering.
> > > Can you do Linux candidates for both c++ library versions?
> > >
> >
> > Just to be sure that I do this in correct way. Currently I'm checking
> > which libraries installed on machines I use for building. Some of them
> > have libstdc++5 and some have both.
> >
> > What is correct way to check that a required library for building is
> > used?
>
> The easiest way is just to check the resulting .so files in
> deploy/jdk/jre/bin with ldd. I thought that the main issue was with the
> icu libraries compiled against libstdc++5 that are in svn.
>
> Earlier this week I checked in versions that use libstdc++.so.6 and
> added an ant flag (-Duse.libstdc++6=true) to use them on the x86 builds.
>
Yes, I saw your commit.
> Thinking about this some more though... we'll have a problem trying to
> build with libstdc++.so.5 because although the libicu* files might use
> libstdc++.so.5 your compiler might default to libstdc++.so.6 for the
> awt native builds. Mine certainly does and I don't know a quick way to
> avoid this.
>
Thanks for the reminding about awt libraries - I forgot about them. My
understanding that we can configure compiler to use required library
via LD_LIBRARY_PATH. Say
$export LD_LIBRARY_PATH=/mydir:$LD_LIBRARY_PATH
$ls -l /mydir
libstdc++.so -> required lib
libstdc++.a -> required archive
I think also it might be necessary to build awt libraries (jpeg, lcms
and png) with required libstdc++.so and place them to
classlib/depends/libs/build dir.
-Stepan.
> I'm afraid I'm going to be without web access until Monday so I can't be
> more help.
>
> -Mark.
Re: [snapshot] Freezing the code for Milestone build?
Posted by Mark Hindess <ma...@googlemail.com>.
On 26 April 2007 at 22:39, "Stepan Mishura" <st...@gmail.com> wrote:
> On 4/26/07, Tim Ellison <t....@gmail.com> wrote:
> > Stepan Mishura wrote:
> > > On 4/26/07, Tim Ellison wrote:
> > >> Mikhail Loenko wrote:
> > >> > We should freeze when all CCs are in the up state [1]
> > >> >
> > >> > Can we use the snapshots [2]? My understanding is that the snapshots
> > >> > are updated in the "all CCs up" moments, so probably almost-a-week old
> > >> > snapshots are the best for the Milestone.
> > >>
> > >> Hey, I must have missed something! Are they updated automatically by
> > >> somebody's build machine?
> > >
> > > I'd say they updated semi-automatically - I've not scheduled the
> > > script which builds and uploads them. And I kick the script when I see
> > > that all CC scenarios pass.
> >
> > I see. Please would you also send mail to the list when you have
> > updated the snapshots so we all know they have changed.
> >
>
> OK, I'm going to add 'release candidate' paragraph with links to
> milestone candidates.
>
> > >> i.e. while we are testing them as candidates
> > >> are they likely to get overwritten?
> > >
> > > I think while we testing release candidates we should keep them on the
> > > site. So it makes sense for me to update the download page with
> > > separate links to release candidates.
> >
> > Agreed, and thanks for volunteering.
> > Can you do Linux candidates for both c++ library versions?
> >
>
> Just to be sure that I do this in correct way. Currently I'm checking
> which libraries installed on machines I use for building. Some of them
> have libstdc++5 and some have both.
>
> What is correct way to check that a required library for building is
> used?
The easiest way is just to check the resulting .so files in
deploy/jdk/jre/bin with ldd. I thought that the main issue was with the
icu libraries compiled against libstdc++5 that are in svn.
Earlier this week I checked in versions that use libstdc++.so.6 and
added an ant flag (-Duse.libstdc++6=true) to use them on the x86 builds.
Thinking about this some more though... we'll have a problem trying to
build with libstdc++.so.5 because although the libicu* files might use
libstdc++.so.5 your compiler might default to libstdc++.so.6 for the
awt native builds. Mine certainly does and I don't know a quick way to
avoid this.
I'm afraid I'm going to be without web access until Monday so I can't be
more help.
-Mark.
Re: [snapshot] Freezing the code for Milestone build?
Posted by Stepan Mishura <st...@gmail.com>.
On 4/26/07, Tim Ellison <t....@gmail.com> wrote:
> Stepan Mishura wrote:
> > On 4/26/07, Tim Ellison wrote:
> >> Mikhail Loenko wrote:
> >> > We should freeze when all CCs are in the up state [1]
> >> >
> >> > Can we use the snapshots [2]? My understanding is that the snapshots
> >> > are updated in the "all CCs up" moments, so probably almost-a-week old
> >> > snapshots are the best for the Milestone.
> >>
> >> Hey, I must have missed something! Are they updated automatically by
> >> somebody's build machine?
> >
> > I'd say they updated semi-automatically - I've not scheduled the
> > script which builds and uploads them. And I kick the script when I see
> > that all CC scenarios pass.
>
> I see. Please would you also send mail to the list when you have
> updated the snapshots so we all know they have changed.
>
OK, I'm going to add 'release candidate' paragraph with links to
milestone candidates.
> >> i.e. while we are testing them as candidates
> >> are they likely to get overwritten?
> >
> > I think while we testing release candidates we should keep them on the
> > site. So it makes sense for me to update the download page with
> > separate links to release candidates.
>
> Agreed, and thanks for volunteering.
> Can you do Linux candidates for both c++ library versions?
>
Just to be sure that I do this in correct way. Currently I'm checking
which libraries installed on machines I use for building. Some of them
have libstdc++5 and some have both.
What is correct way to check that a required library for building is used?
Thanks,
Stepan.
Re: [snapshot] Freezing the code for Milestone build?
Posted by Tim Ellison <t....@gmail.com>.
Stepan Mishura wrote:
> On 4/26/07, Tim Ellison wrote:
>> Mikhail Loenko wrote:
>> > We should freeze when all CCs are in the up state [1]
>> >
>> > Can we use the snapshots [2]? My understanding is that the snapshots
>> > are updated in the "all CCs up" moments, so probably almost-a-week old
>> > snapshots are the best for the Milestone.
>>
>> Hey, I must have missed something! Are they updated automatically by
>> somebody's build machine?
>
> I'd say they updated semi-automatically - I've not scheduled the
> script which builds and uploads them. And I kick the script when I see
> that all CC scenarios pass.
I see. Please would you also send mail to the list when you have
updated the snapshots so we all know they have changed.
>> i.e. while we are testing them as candidates
>> are they likely to get overwritten?
>
> I think while we testing release candidates we should keep them on the
> site. So it makes sense for me to update the download page with
> separate links to release candidates.
Agreed, and thanks for volunteering.
Can you do Linux candidates for both c++ library versions?
Regards,
Tim
Re: [snapshot] Freezing the code for Milestone build?
Posted by Stepan Mishura <st...@gmail.com>.
On 4/26/07, Tim Ellison wrote:
> Mikhail Loenko wrote:
> > We should freeze when all CCs are in the up state [1]
> >
> > Can we use the snapshots [2]? My understanding is that the snapshots
> > are updated in the "all CCs up" moments, so probably almost-a-week old
> > snapshots are the best for the Milestone.
>
> Hey, I must have missed something! Are they updated automatically by
> somebody's build machine?
I'd say they updated semi-automatically - I've not scheduled the
script which builds and uploads them. And I kick the script when I see
that all CC scenarios pass.
> i.e. while we are testing them as candidates
> are they likely to get overwritten?
>
I think while we testing release candidates we should keep them on the
site. So it makes sense for me to update the download page with
separate links to release candidates.
-Stepan.
> I assume these linux builds require c++ v5, right?
>
> > Were there any significant changes since that? I know about gc switch,
> > but not sure how it affected stability...
>
> It is certainly something that we should spend some time banging on
> before declaring stability.
>
> Regards,
> Tim
>
--
Stepan Mishura
Intel Enterprise Solutions Software Division
Re: [snapshot] Freezing the code for Milestone build?
Posted by Tim Ellison <t....@gmail.com>.
Mikhail Loenko wrote:
> We should freeze when all CCs are in the up state [1]
>
> Can we use the snapshots [2]? My understanding is that the snapshots
> are updated in the "all CCs up" moments, so probably almost-a-week old
> snapshots are the best for the Milestone.
Hey, I must have missed something! Are they updated automatically by
somebody's build machine? i.e. while we are testing them as candidates
are they likely to get overwritten?
I assume these linux builds require c++ v5, right?
> Were there any significant changes since that? I know about gc switch,
> but not sure how it affected stability...
It is certainly something that we should spend some time banging on
before declaring stability.
Regards,
Tim
Re: [snapshot] Freezing the code for Milestone build?
Posted by Vladimir Ivanov <iv...@gmail.com>.
Actually, not yet. Eclipse 3.1.1 failed to start in my env on WinXP :(
Probably, Ivan found the root cause for this failure (thread:
[drlvm][eclipse] eclipse failed to start today in my env on WinXp
x86).
thanks, Vladimir
On 4/27/07, Mikhail Loenko <ml...@gmail.com> wrote:
> Vladimir wrote about problem with launching Eclipse. Was it resolved?
>
> 2007/4/27, Alexey Petrenko <al...@gmail.com>:
> > Great. So CCs for x86 are up and all the critical issues are resolved.
> > It looks like time for freeze and prepare a build.
> >
> > Did I forget something? Any other critical issues?
> >
> > SY, Alexey
> >
> > 2007/4/27, Gregory Shimansky <gs...@apache.org>:
> > > Alexey Petrenko wrote:
> > > > DRLVM has been switched back to GCv4.
> > > > HARMONY-3764 "[drlvm][build] jar with kernel classes' sources is not
> > > > generated" has been resolved
> > > > Patch for HARMONY-3730 "[drlvm][jvmti] SINGLE_STEP events are not
> > > > reported in JIT mode" has been applied but the issue is not closed.
> > > > Gregory, do you have anything to do with this issue or you just forgot
> > > > to press resolve button? :)
> > >
> > > Sorry, just forgot to mark it resolved indeed. Done now.
> > >
> > > > 2007/4/26, Tim Ellison <t....@gmail.com>:
> > > >> Xiao-Feng Li wrote:
> > > >> > On 4/26/07, Sergey Kuksenko <se...@gmail.com> wrote:
> > > >> >> Hi All,
> > > >> >>
> > > >> >> I wish to notify that GCv5 currently has a stability problem.
> > > >> >>
> > > >> >> http://issues.apache.org/jira/browse/HARMONY-3746
> > > >> >> I think We should fix the bug before freese or switch back to GCv4.1.
> > > >> >>
> > > >> >
> > > >> > I noticed that, and am trying to reproduce it, so far can't reproduce
> > > >> > it locally. I am now trying to connect the test machine to check the
> > > >> > problem. Hopefully it can be fixed quite soon within two days.
> > > >> > Otherwise, I'd vote to switch it back to GCv4.1.
> > > >> >
> > > >> > The other solution would be to choose a revision and make a release
> > > >> > branch from it. Then we don't need to freeze the code base for new
> > > >> > developments. This is actually common for industry product release.
> > > >>
> > > >> Ok, let's wait and see what you conclude.
> > > >>
> > > >> Regards,
> > > >> Tim
> > > >>
> > > >
> > >
> > >
> > > --
> > > Gregory
> > >
> > >
> >
>
Re: [snapshot] Freezing the code for Milestone build?
Posted by Mikhail Loenko <ml...@gmail.com>.
Vladimir wrote about problem with launching Eclipse. Was it resolved?
2007/4/27, Alexey Petrenko <al...@gmail.com>:
> Great. So CCs for x86 are up and all the critical issues are resolved.
> It looks like time for freeze and prepare a build.
>
> Did I forget something? Any other critical issues?
>
> SY, Alexey
>
> 2007/4/27, Gregory Shimansky <gs...@apache.org>:
> > Alexey Petrenko wrote:
> > > DRLVM has been switched back to GCv4.
> > > HARMONY-3764 "[drlvm][build] jar with kernel classes' sources is not
> > > generated" has been resolved
> > > Patch for HARMONY-3730 "[drlvm][jvmti] SINGLE_STEP events are not
> > > reported in JIT mode" has been applied but the issue is not closed.
> > > Gregory, do you have anything to do with this issue or you just forgot
> > > to press resolve button? :)
> >
> > Sorry, just forgot to mark it resolved indeed. Done now.
> >
> > > 2007/4/26, Tim Ellison <t....@gmail.com>:
> > >> Xiao-Feng Li wrote:
> > >> > On 4/26/07, Sergey Kuksenko <se...@gmail.com> wrote:
> > >> >> Hi All,
> > >> >>
> > >> >> I wish to notify that GCv5 currently has a stability problem.
> > >> >>
> > >> >> http://issues.apache.org/jira/browse/HARMONY-3746
> > >> >> I think We should fix the bug before freese or switch back to GCv4.1.
> > >> >>
> > >> >
> > >> > I noticed that, and am trying to reproduce it, so far can't reproduce
> > >> > it locally. I am now trying to connect the test machine to check the
> > >> > problem. Hopefully it can be fixed quite soon within two days.
> > >> > Otherwise, I'd vote to switch it back to GCv4.1.
> > >> >
> > >> > The other solution would be to choose a revision and make a release
> > >> > branch from it. Then we don't need to freeze the code base for new
> > >> > developments. This is actually common for industry product release.
> > >>
> > >> Ok, let's wait and see what you conclude.
> > >>
> > >> Regards,
> > >> Tim
> > >>
> > >
> >
> >
> > --
> > Gregory
> >
> >
>
Re: [snapshot] Freezing the code for Milestone build?
Posted by Alexey Petrenko <al...@gmail.com>.
Great. So CCs for x86 are up and all the critical issues are resolved.
It looks like time for freeze and prepare a build.
Did I forget something? Any other critical issues?
SY, Alexey
2007/4/27, Gregory Shimansky <gs...@apache.org>:
> Alexey Petrenko wrote:
> > DRLVM has been switched back to GCv4.
> > HARMONY-3764 "[drlvm][build] jar with kernel classes' sources is not
> > generated" has been resolved
> > Patch for HARMONY-3730 "[drlvm][jvmti] SINGLE_STEP events are not
> > reported in JIT mode" has been applied but the issue is not closed.
> > Gregory, do you have anything to do with this issue or you just forgot
> > to press resolve button? :)
>
> Sorry, just forgot to mark it resolved indeed. Done now.
>
> > 2007/4/26, Tim Ellison <t....@gmail.com>:
> >> Xiao-Feng Li wrote:
> >> > On 4/26/07, Sergey Kuksenko <se...@gmail.com> wrote:
> >> >> Hi All,
> >> >>
> >> >> I wish to notify that GCv5 currently has a stability problem.
> >> >>
> >> >> http://issues.apache.org/jira/browse/HARMONY-3746
> >> >> I think We should fix the bug before freese or switch back to GCv4.1.
> >> >>
> >> >
> >> > I noticed that, and am trying to reproduce it, so far can't reproduce
> >> > it locally. I am now trying to connect the test machine to check the
> >> > problem. Hopefully it can be fixed quite soon within two days.
> >> > Otherwise, I'd vote to switch it back to GCv4.1.
> >> >
> >> > The other solution would be to choose a revision and make a release
> >> > branch from it. Then we don't need to freeze the code base for new
> >> > developments. This is actually common for industry product release.
> >>
> >> Ok, let's wait and see what you conclude.
> >>
> >> Regards,
> >> Tim
> >>
> >
>
>
> --
> Gregory
>
>
Re: [snapshot] Freezing the code for Milestone build?
Posted by Gregory Shimansky <gs...@apache.org>.
Alexey Petrenko wrote:
> DRLVM has been switched back to GCv4.
> HARMONY-3764 "[drlvm][build] jar with kernel classes' sources is not
> generated" has been resolved
> Patch for HARMONY-3730 "[drlvm][jvmti] SINGLE_STEP events are not
> reported in JIT mode" has been applied but the issue is not closed.
> Gregory, do you have anything to do with this issue or you just forgot
> to press resolve button? :)
Sorry, just forgot to mark it resolved indeed. Done now.
> 2007/4/26, Tim Ellison <t....@gmail.com>:
>> Xiao-Feng Li wrote:
>> > On 4/26/07, Sergey Kuksenko <se...@gmail.com> wrote:
>> >> Hi All,
>> >>
>> >> I wish to notify that GCv5 currently has a stability problem.
>> >>
>> >> http://issues.apache.org/jira/browse/HARMONY-3746
>> >> I think We should fix the bug before freese or switch back to GCv4.1.
>> >>
>> >
>> > I noticed that, and am trying to reproduce it, so far can't reproduce
>> > it locally. I am now trying to connect the test machine to check the
>> > problem. Hopefully it can be fixed quite soon within two days.
>> > Otherwise, I'd vote to switch it back to GCv4.1.
>> >
>> > The other solution would be to choose a revision and make a release
>> > branch from it. Then we don't need to freeze the code base for new
>> > developments. This is actually common for industry product release.
>>
>> Ok, let's wait and see what you conclude.
>>
>> Regards,
>> Tim
>>
>
--
Gregory
Re: [snapshot] Freezing the code for Milestone build?
Posted by Alexey Petrenko <al...@gmail.com>.
DRLVM has been switched back to GCv4.
HARMONY-3764 "[drlvm][build] jar with kernel classes' sources is not
generated" has been resolved
Patch for HARMONY-3730 "[drlvm][jvmti] SINGLE_STEP events are not
reported in JIT mode" has been applied but the issue is not closed.
Gregory, do you have anything to do with this issue or you just forgot
to press resolve button? :)
SY, Alexey
2007/4/26, Tim Ellison <t....@gmail.com>:
> Xiao-Feng Li wrote:
> > On 4/26/07, Sergey Kuksenko <se...@gmail.com> wrote:
> >> Hi All,
> >>
> >> I wish to notify that GCv5 currently has a stability problem.
> >>
> >> http://issues.apache.org/jira/browse/HARMONY-3746
> >> I think We should fix the bug before freese or switch back to GCv4.1.
> >>
> >
> > I noticed that, and am trying to reproduce it, so far can't reproduce
> > it locally. I am now trying to connect the test machine to check the
> > problem. Hopefully it can be fixed quite soon within two days.
> > Otherwise, I'd vote to switch it back to GCv4.1.
> >
> > The other solution would be to choose a revision and make a release
> > branch from it. Then we don't need to freeze the code base for new
> > developments. This is actually common for industry product release.
>
> Ok, let's wait and see what you conclude.
>
> Regards,
> Tim
>
Re: [snapshot] Freezing the code for Milestone build?
Posted by Tim Ellison <t....@gmail.com>.
Xiao-Feng Li wrote:
> On 4/26/07, Sergey Kuksenko <se...@gmail.com> wrote:
>> Hi All,
>>
>> I wish to notify that GCv5 currently has a stability problem.
>>
>> http://issues.apache.org/jira/browse/HARMONY-3746
>> I think We should fix the bug before freese or switch back to GCv4.1.
>>
>
> I noticed that, and am trying to reproduce it, so far can't reproduce
> it locally. I am now trying to connect the test machine to check the
> problem. Hopefully it can be fixed quite soon within two days.
> Otherwise, I'd vote to switch it back to GCv4.1.
>
> The other solution would be to choose a revision and make a release
> branch from it. Then we don't need to freeze the code base for new
> developments. This is actually common for industry product release.
Ok, let's wait and see what you conclude.
Regards,
Tim
Re: [snapshot] Freezing the code for Milestone build?
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 4/26/07, Sergey Kuksenko <se...@gmail.com> wrote:
> Hi All,
>
> I wish to notify that GCv5 currently has a stability problem.
>
> http://issues.apache.org/jira/browse/HARMONY-3746
> I think We should fix the bug before freese or switch back to GCv4.1.
>
I noticed that, and am trying to reproduce it, so far can't reproduce
it locally. I am now trying to connect the test machine to check the
problem. Hopefully it can be fixed quite soon within two days.
Otherwise, I'd vote to switch it back to GCv4.1.
The other solution would be to choose a revision and make a release
branch from it. Then we don't need to freeze the code base for new
developments. This is actually common for industry product release.
Thanks,
xiaofeng
> --
> Best regards,
> ---
> Sergey Kuksenko.
> Intel Enterprise Solutions Software Division.
>
--
http://xiao-feng.blogspot.com
Re: [snapshot] Freezing the code for Milestone build?
Posted by Sergey Kuksenko <se...@gmail.com>.
Hi All,
I wish to notify that GCv5 currently has a stability problem.
http://issues.apache.org/jira/browse/HARMONY-3746
I think We should fix the bug before freese or switch back to GCv4.1.
--
Best regards,
---
Sergey Kuksenko.
Intel Enterprise Solutions Software Division.
Re: [snapshot] Freezing the code for Milestone build?
Posted by Alexey Petrenko <al...@gmail.com>.
We got one issue marked as blocker:
HARMONY-3746 [drlvm][gc_gen] DRLVM failed on SPECjbb2005 with GCv5.
http://issues.apache.org/jira/browse/HARMONY-3746
SY, Alexey
2007/4/26, Tim Ellison <t....@gmail.com>:
> Yang Paulex wrote:
> > 2007/4/26, Mikhail Loenko <ml...@gmail.com>:
> >>
> >> We should freeze when all CCs are in the up state [1]
> >
> >
> > Agreed, but every CC needs some time to generate report, so does it make
> > sense to
> > 1. freeze for some while
> > 2. Hold breath and wait for the results
> > 3. fix regression failures if any but no other commits
> > 4. repeat 1-3 until everything is fine
> >
> > I suppose 1 day is probably enough for these?
>
> Yes, and I was hoping that we could spend that day also running some
> applications to reinforce our confidence in the builds.
>
> I understand that there are still a number of known problems, but it
> would be a shame if there was a trivial blocker that prevented us from
> showing the true capabilities of the code to date.
>
> This milestone is the one we'll point to at ApacheCon next week and
> JavaOne the week after.
>
> Regards,
> Tim
>
Re: [snapshot] Freezing the code for Milestone build?
Posted by Tim Ellison <t....@gmail.com>.
Yang Paulex wrote:
> 2007/4/26, Mikhail Loenko <ml...@gmail.com>:
>>
>> We should freeze when all CCs are in the up state [1]
>
>
> Agreed, but every CC needs some time to generate report, so does it make
> sense to
> 1. freeze for some while
> 2. Hold breath and wait for the results
> 3. fix regression failures if any but no other commits
> 4. repeat 1-3 until everything is fine
>
> I suppose 1 day is probably enough for these?
Yes, and I was hoping that we could spend that day also running some
applications to reinforce our confidence in the builds.
I understand that there are still a number of known problems, but it
would be a shame if there was a trivial blocker that prevented us from
showing the true capabilities of the code to date.
This milestone is the one we'll point to at ApacheCon next week and
JavaOne the week after.
Regards,
Tim
Re: [snapshot] Freezing the code for Milestone build?
Posted by Yang Paulex <pa...@gmail.com>.
2007/4/26, Mikhail Loenko <ml...@gmail.com>:
>
> We should freeze when all CCs are in the up state [1]
Agreed, but every CC needs some time to generate report, so does it make
sense to
1. freeze for some while
2. Hold breath and wait for the results
3. fix regression failures if any but no other commits
4. repeat 1-3 until everything is fine
I suppose 1 day is probably enough for these?
Can we use the snapshots [2]? My understanding is that the snapshots
> are updated in the "all CCs up" moments, so probably almost-a-week old
> snapshots are the best for the Milestone.
>
> Were there any significant changes since that? I know about gc switch,
> but not sure how it affected stability...
>
> Thanks,
> Mikhail
>
> [1] http://www.harmonytest.org/upload/cc1.html
> [2] http://people.apache.org/builds/harmony/snapshots/
>
> 2007/4/26, Tim Ellison <t....@gmail.com>:
> > To ensure we get a stable build we need to freeze the code for a short
> > duration, which will allow us to:
> >
> > - produce the set of milestone candidates,
> > i.e. a full rebuild on Windows, Linux (with libstdc++ v5 dependency)
> > and Linux (with libstdc++ v6 dependency) in JRE, JDK, and HDK
> > formats. At this point we will still only publish x86 snapshots.
> >
> > - test the snapshots,
> > i.e. test installs (it would be good if you have a machine without
> > your usual development environment set up to ensure we don't have
> > dependencies on dev tools); and testing various applications to check
> > they work as well as we would expect for this snapshot.
> >
> > While we do this it is helpful if the codebase is not being changed. It
> > sounds like people are happy enough to freeze HEAD rather than create a
> > branch, so let's do that.
> >
> > During the freeze there should be no commits unless we agree here on the
> > dev list that there is a problem serious enough for us to re-spin a new
> > candidate. I would hope that producing the snapshots and some focused
> > testing can happen over one or two days (max) to declare the build good.
> > Once the milestone is declared good we will reopen for development as
> > usual.
> >
> > Does that sound like a reasonable procedure? Did I miss anything out?
> >
> > so:
> > - when do we freeze (today/tomorrow)? any outstanding MUST fix's?
> > - volunteers with machines for producing the candidates?
> >
> > Regards,
> > Tim
> >
>
--
Paulex Yang
China Software Development laboratory
IBM
Re: [snapshot] Freezing the code for Milestone build?
Posted by Stepan Mishura <st...@gmail.com>.
On 4/26/07, Mikhail Loenko <ml...@gmail.com> wrote:
> We should freeze when all CCs are in the up state [1]
>
> Can we use the snapshots [2]? My understanding is that the snapshots
> are updated in the "all CCs up" moments, so probably almost-a-week old
> snapshots are the best for the Milestone.
>
> Were there any significant changes since that? I know about gc switch,
> but not sure how it affected stability...
>
Mikhail,
I created the last snapshots just before gc switch. I've not refreshed
them since that time because of CC alerts.
Thanks,
Stepan.
> Thanks,
> Mikhail
>
> [1] http://www.harmonytest.org/upload/cc1.html
> [2] http://people.apache.org/builds/harmony/snapshots/
>
> 2007/4/26, Tim Ellison <t....@gmail.com>:
> > To ensure we get a stable build we need to freeze the code for a short
> > duration, which will allow us to:
> >
> > - produce the set of milestone candidates,
> > i.e. a full rebuild on Windows, Linux (with libstdc++ v5 dependency)
> > and Linux (with libstdc++ v6 dependency) in JRE, JDK, and HDK
> > formats. At this point we will still only publish x86 snapshots.
> >
> > - test the snapshots,
> > i.e. test installs (it would be good if you have a machine without
> > your usual development environment set up to ensure we don't have
> > dependencies on dev tools); and testing various applications to check
> > they work as well as we would expect for this snapshot.
> >
> > While we do this it is helpful if the codebase is not being changed. It
> > sounds like people are happy enough to freeze HEAD rather than create a
> > branch, so let's do that.
> >
> > During the freeze there should be no commits unless we agree here on the
> > dev list that there is a problem serious enough for us to re-spin a new
> > candidate. I would hope that producing the snapshots and some focused
> > testing can happen over one or two days (max) to declare the build good.
> > Once the milestone is declared good we will reopen for development as
> > usual.
> >
> > Does that sound like a reasonable procedure? Did I miss anything out?
> >
> > so:
> > - when do we freeze (today/tomorrow)? any outstanding MUST fix's?
> > - volunteers with machines for producing the candidates?
> >
> > Regards,
> > Tim
> >
>
--
Stepan Mishura
Intel Enterprise Solutions Software Division
Re: [snapshot] Freezing the code for Milestone build?
Posted by Mikhail Loenko <ml...@gmail.com>.
We should freeze when all CCs are in the up state [1]
Can we use the snapshots [2]? My understanding is that the snapshots
are updated in the "all CCs up" moments, so probably almost-a-week old
snapshots are the best for the Milestone.
Were there any significant changes since that? I know about gc switch,
but not sure how it affected stability...
Thanks,
Mikhail
[1] http://www.harmonytest.org/upload/cc1.html
[2] http://people.apache.org/builds/harmony/snapshots/
2007/4/26, Tim Ellison <t....@gmail.com>:
> To ensure we get a stable build we need to freeze the code for a short
> duration, which will allow us to:
>
> - produce the set of milestone candidates,
> i.e. a full rebuild on Windows, Linux (with libstdc++ v5 dependency)
> and Linux (with libstdc++ v6 dependency) in JRE, JDK, and HDK
> formats. At this point we will still only publish x86 snapshots.
>
> - test the snapshots,
> i.e. test installs (it would be good if you have a machine without
> your usual development environment set up to ensure we don't have
> dependencies on dev tools); and testing various applications to check
> they work as well as we would expect for this snapshot.
>
> While we do this it is helpful if the codebase is not being changed. It
> sounds like people are happy enough to freeze HEAD rather than create a
> branch, so let's do that.
>
> During the freeze there should be no commits unless we agree here on the
> dev list that there is a problem serious enough for us to re-spin a new
> candidate. I would hope that producing the snapshots and some focused
> testing can happen over one or two days (max) to declare the build good.
> Once the milestone is declared good we will reopen for development as
> usual.
>
> Does that sound like a reasonable procedure? Did I miss anything out?
>
> so:
> - when do we freeze (today/tomorrow)? any outstanding MUST fix's?
> - volunteers with machines for producing the candidates?
>
> Regards,
> Tim
>
Re: [snapshot] Freezing the code for Milestone build?
Posted by Alexei Zakharov <al...@gmail.com>.
In case if nobody objects I'd also like to bring the fix for
HARMONY-3764 (java sources for kernel classes) in before the freeze.
Eclipse guys has sent us a request about this (in "Eclipse doesn't
find harmony sources" thread).
Regards,
2007/4/26, Gregory Shimansky <gs...@apache.org>:
> Tim Ellison wrote:
> > To ensure we get a stable build we need to freeze the code for a short
> > duration, which will allow us to:
> >
> > - produce the set of milestone candidates,
> > i.e. a full rebuild on Windows, Linux (with libstdc++ v5 dependency)
> > and Linux (with libstdc++ v6 dependency) in JRE, JDK, and HDK
> > formats. At this point we will still only publish x86 snapshots.
> >
> > - test the snapshots,
> > i.e. test installs (it would be good if you have a machine without
> > your usual development environment set up to ensure we don't have
> > dependencies on dev tools); and testing various applications to check
> > they work as well as we would expect for this snapshot.
> >
> > While we do this it is helpful if the codebase is not being changed. It
> > sounds like people are happy enough to freeze HEAD rather than create a
> > branch, so let's do that.
> >
> > During the freeze there should be no commits unless we agree here on the
> > dev list that there is a problem serious enough for us to re-spin a new
> > candidate. I would hope that producing the snapshots and some focused
> > testing can happen over one or two days (max) to declare the build good.
> > Once the milestone is declared good we will reopen for development as
> > usual.
> >
> > Does that sound like a reasonable procedure? Did I miss anything out?
> >
> > so:
> > - when do we freeze (today/tomorrow)? any outstanding MUST fix's?
>
> I am going to commit patch in HARMONY-3730 in no one objects. The bug is
> marked critical and the fix for it is simple and doesn't affect stability.
>
> > - volunteers with machines for producing the candidates?
> >
> > Regards,
> > Tim
> >
>
>
> --
> Gregory
>
>
--
Alexei Zakharov,
Intel ESSD
Re: [snapshot] Freezing the code for Milestone build?
Posted by Gregory Shimansky <gs...@apache.org>.
Tim Ellison wrote:
> To ensure we get a stable build we need to freeze the code for a short
> duration, which will allow us to:
>
> - produce the set of milestone candidates,
> i.e. a full rebuild on Windows, Linux (with libstdc++ v5 dependency)
> and Linux (with libstdc++ v6 dependency) in JRE, JDK, and HDK
> formats. At this point we will still only publish x86 snapshots.
>
> - test the snapshots,
> i.e. test installs (it would be good if you have a machine without
> your usual development environment set up to ensure we don't have
> dependencies on dev tools); and testing various applications to check
> they work as well as we would expect for this snapshot.
>
> While we do this it is helpful if the codebase is not being changed. It
> sounds like people are happy enough to freeze HEAD rather than create a
> branch, so let's do that.
>
> During the freeze there should be no commits unless we agree here on the
> dev list that there is a problem serious enough for us to re-spin a new
> candidate. I would hope that producing the snapshots and some focused
> testing can happen over one or two days (max) to declare the build good.
> Once the milestone is declared good we will reopen for development as
> usual.
>
> Does that sound like a reasonable procedure? Did I miss anything out?
>
> so:
> - when do we freeze (today/tomorrow)? any outstanding MUST fix's?
I am going to commit patch in HARMONY-3730 in no one objects. The bug is
marked critical and the fix for it is simple and doesn't affect stability.
> - volunteers with machines for producing the candidates?
>
> Regards,
> Tim
>
--
Gregory