Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
On Dec 4, 2012, at 4:18 PM, Steve Rowe wrote: > I'm running it. It takes just over 4 minutes for me. Pretty minor IMHO. I suppose if you have long tests anyway - typically my solr tests run takes 3:30 to 4 minutes, so doubling my time is not really something I'm ready to swallow. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
I'm running it. It takes just over 4 minutes for me. Pretty minor IMHO. On Dec 4, 2012, at 5:26 PM, Mark Miller wrote: > I guess my point is that since no one runs it (except perhaps you), it's not > really helping anything. > > And the "broken build" is really more minor than a true broken build if tests > at least still pass. Personally, I'm pretty okay with a nocommit failing the > build for 30 minutes if the tests still pass. > > Most of these issues are basic enough that anyone can jump in and fix it if > it's causing them issues as well. Just remove the tabs, fix the javadoc, etc. > > - Mark > > On Dec 4, 2012, at 12:56 PM, Robert Muir wrote: > >> >> >> On Tue, Dec 4, 2012 at 3:33 PM, Mark Miller wrote: >> We are not talking about weakening them on Jenkins though. It won't wait >> till release time, it will be caught 10 min later by Jenkins. >> >> >> Right but that then doesnt really improve the situation (its less than 10 >> minutes to check locally), >> because if someone does "commit-and-run" we are still left with a broke >> build. >> >> I'm not concerned about this stuff tripping at all if people are looking out >> and fixing stuff. >> >> I do have some concerns about not running the javadocs checks, because part >> of the point is "check everything we can automatically" since it makes >> someone go and look at the file and perhaps then they also see some text is >> out of date too (not just syntax). I'm not trying to say the system is >> perfect or even works, only time will tell. But I do feel like it helps keep >> the documentation from falling out of date, especially when the stuff is >> fresh in the committers mind. > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
I guess my point is that since no one runs it (except perhaps you), it's not really helping anything. And the "broken build" is really more minor than a true broken build if tests at least still pass. Personally, I'm pretty okay with a nocommit failing the build for 30 minutes if the tests still pass. Most of these issues are basic enough that anyone can jump in and fix it if it's causing them issues as well. Just remove the tabs, fix the javadoc, etc. - Mark On Dec 4, 2012, at 12:56 PM, Robert Muir wrote: > > > On Tue, Dec 4, 2012 at 3:33 PM, Mark Miller wrote: > We are not talking about weakening them on Jenkins though. It won't wait till > release time, it will be caught 10 min later by Jenkins. > > > Right but that then doesnt really improve the situation (its less than 10 > minutes to check locally), > because if someone does "commit-and-run" we are still left with a broke build. > > I'm not concerned about this stuff tripping at all if people are looking out > and fixing stuff. > > I do have some concerns about not running the javadocs checks, because part > of the point is "check everything we can automatically" since it makes > someone go and look at the file and perhaps then they also see some text is > out of date too (not just syntax). I'm not trying to say the system is > perfect or even works, only time will tell. But I do feel like it helps keep > the documentation from falling out of date, especially when the stuff is > fresh in the committers mind. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
On Tue, Dec 4, 2012 at 3:33 PM, Mark Miller wrote: > We are not talking about weakening them on Jenkins though. It won't wait > till release time, it will be caught 10 min later by Jenkins. > > Right but that then doesnt really improve the situation (its less than 10 minutes to check locally), because if someone does "commit-and-run" we are still left with a broke build. I'm not concerned about this stuff tripping at all if people are looking out and fixing stuff. I do have some concerns about not running the javadocs checks, because part of the point is "check everything we can automatically" since it makes someone go and look at the file and perhaps then they also see some text is out of date too (not just syntax). I'm not trying to say the system is perfect or even works, only time will tell. But I do feel like it helps keep the documentation from falling out of date, especially when the stuff is fresh in the committers mind.
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
We are not talking about weakening them on Jenkins though. It won't wait till
release time, it will be caught 10 min later by Jenkins.
But if we can make it faster and keep all the checks, then by all means!
Mark
Sent from my iPhone
On Dec 4, 2012, at 12:23 PM, Robert Muir wrote:
> I think the slowness problem can be fixed way easier than that.
>
> Actually in my opinion the main bug is the speed of building javadocs
> themselves. Today this requires lots of building of useless jars and some
> other things that are unnecessary.
> I also think javadocs for a module get "rebuilt" across the whole thing
> because they are depended on by some other module's javadocs, and so on.
>
> I really don't think the checks should be weakened in any way. These checks
> are necessary (people will complain about them at release vote time, so we
> have to keep the codebase in good order and not just all make a mess for
> months, waiting for some RM to clean it up).
>
>
> On Tue, Dec 4, 2012 at 3:16 PM, Steve Rowe wrote:
>> I think one useful middle point might be to only run checks on modules that
>> have pending changes. Yes, as Hoss points out, an unchanged module's
>> javadocs might no longer work (etc.), but I don't think that's the common
>> case.
>>
>> On Dec 4, 2012, at 3:00 PM, Mark Miller wrote:
>>
>> > Well perhaps there is a middle ground - 'quasi-precommit' that just checks
>> > fast stuff per module… (eg doesn't build all the javadocs)
>> >
>> > Then we would catch more, but perhaps not everything.
>> >
>> > Precommit is scary slow and if it's so slow no one will use it, it's
>> > almost not so helpful.
>> >
>> > - Mark
>> >
>> > On Dec 4, 2012, at 11:53 AM, Chris Hostetter
>> > wrote:
>> >
>> >>
>> >> : I'd really love to have a per-module "ant precommit".
>> >>
>> >> That's not really viable is it?
>> >>
>> >> small tweaks in one class might leave everything fine and dandy in that
>> >> module, but another module that depends on it could break as a result (eg:
>> >> removing a method/variable that is {@link}ed to, etc...)
>> >>
>> >>
>> >> -Hoss
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
I think the slowness problem can be fixed way easier than that.
Actually in my opinion the main bug is the speed of building javadocs
themselves. Today this requires lots of building of useless jars and some
other things that are unnecessary.
I also think javadocs for a module get "rebuilt" across the whole thing
because they are depended on by some other module's javadocs, and so on.
I really don't think the checks should be weakened in any way. These checks
are necessary (people will complain about them at release vote time, so we
have to keep the codebase in good order and not just all make a mess for
months, waiting for some RM to clean it up).
On Tue, Dec 4, 2012 at 3:16 PM, Steve Rowe wrote:
> I think one useful middle point might be to only run checks on modules
> that have pending changes. Yes, as Hoss points out, an unchanged module's
> javadocs might no longer work (etc.), but I don't think that's the common
> case.
>
> On Dec 4, 2012, at 3:00 PM, Mark Miller wrote:
>
> > Well perhaps there is a middle ground - 'quasi-precommit' that just
> checks fast stuff per module… (eg doesn't build all the javadocs)
> >
> > Then we would catch more, but perhaps not everything.
> >
> > Precommit is scary slow and if it's so slow no one will use it, it's
> almost not so helpful.
> >
> > - Mark
> >
> > On Dec 4, 2012, at 11:53 AM, Chris Hostetter
> wrote:
> >
> >>
> >> : I'd really love to have a per-module "ant precommit".
> >>
> >> That's not really viable is it?
> >>
> >> small tweaks in one class might leave everything fine and dandy in that
> >> module, but another module that depends on it could break as a result
> (eg:
> >> removing a method/variable that is {@link}ed to, etc...)
> >>
> >>
> >> -Hoss
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
I think one useful middle point might be to only run checks on modules that
have pending changes. Yes, as Hoss points out, an unchanged module's javadocs
might no longer work (etc.), but I don't think that's the common case.
On Dec 4, 2012, at 3:00 PM, Mark Miller wrote:
> Well perhaps there is a middle ground - 'quasi-precommit' that just checks
> fast stuff per module… (eg doesn't build all the javadocs)
>
> Then we would catch more, but perhaps not everything.
>
> Precommit is scary slow and if it's so slow no one will use it, it's almost
> not so helpful.
>
> - Mark
>
> On Dec 4, 2012, at 11:53 AM, Chris Hostetter wrote:
>
>>
>> : I'd really love to have a per-module "ant precommit".
>>
>> That's not really viable is it?
>>
>> small tweaks in one class might leave everything fine and dandy in that
>> module, but another module that depends on it could break as a result (eg:
>> removing a method/variable that is {@link}ed to, etc...)
>>
>>
>> -Hoss
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
On Tue, Dec 4, 2012 at 3:00 PM, Mark Miller wrote: > Well perhaps there is a middle ground - 'quasi-precommit' that just checks > fast stuff per module… (eg doesn't build all the javadocs) Right, is seems like a good number off the checks (no tabs, nocommits, author tags, ecj is happy) can be done only on the current module ... > Precommit is scary slow and if it's so slow no one will use it, it's almost > not so helpful. Especially when the original change is trivial (all I did was rename a boolean param, and add some javadocs about it, here). Hmm I wonder if we could parallelize it ... Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
Well perhaps there is a middle ground - 'quasi-precommit' that just checks fast
stuff per module… (eg doesn't build all the javadocs)
Then we would catch more, but perhaps not everything.
Precommit is scary slow and if it's so slow no one will use it, it's almost not
so helpful.
- Mark
On Dec 4, 2012, at 11:53 AM, Chris Hostetter wrote:
>
> : I'd really love to have a per-module "ant precommit".
>
> That's not really viable is it?
>
> small tweaks in one class might leave everything fine and dandy in that
> module, but another module that depends on it could break as a result (eg:
> removing a method/variable that is {@link}ed to, etc...)
>
>
> -Hoss
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
: I'd really love to have a per-module "ant precommit".
That's not really viable is it?
small tweaks in one class might leave everything fine and dandy in that
module, but another module that depends on it could break as a result (eg:
removing a method/variable that is {@link}ed to, etc...)
-Hoss
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
On Dec 4, 2012, at 2:45 PM, Michael McCandless wrote: > I'd really love to have a per-module "ant precommit". +1 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
Yes, my bad, sorry :( I share your view that it's annoyingly slow to run the top-level "ant precommit", especially when it's a tiny change. So this time I took a shortcut and ran "ant javadocs" in lucene/core as a proxy for a top-level "ant precommit", yet that was not good enough because the ecj compiler is more picky. I'd really love to have a per-module "ant precommit". Mike McCandless http://blog.mikemccandless.com On Tue, Dec 4, 2012 at 2:25 PM, Mark Miller wrote: > You should take a look at the precommit target you pointed me at! > > - Mark > > On Dec 2, 2012, at 3:00 PM, Michael McCandless > wrote: > >> Woops, I committed a fix ... >> >> Mike McCandless >> >> http://blog.mikemccandless.com >> >> >> On Sun, Dec 2, 2012 at 5:53 PM, Policeman Jenkins Server >> wrote: >>> Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/3026/ >>> Java: 32bit/jdk1.7.0_09 -server -XX:+UseParallelGC >>> >>> All tests passed >>> >>> Build Log: >>> [...truncated 25027 lines...] >>> BUILD FAILED >>> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:60: The >>> following error occurred while executing this line: >>> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:285: >>> The following error occurred while executing this line: >>> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1526: >>> The following error occurred while executing this line: >>> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1560: >>> Compile failed; see the compiler error output for details. >>> >>> Total time: 28 minutes 52 seconds >>> Build step 'Invoke Ant' marked build as failure >>> Archiving artifacts >>> Recording test results >>> Description set: Java: 32bit/jdk1.7.0_09 -server -XX:+UseParallelGC >>> Email was triggered for: Failure >>> Sending email for trigger: Failure >>> >>> >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
You should take a look at the precommit target you pointed me at! - Mark On Dec 2, 2012, at 3:00 PM, Michael McCandless wrote: > Woops, I committed a fix ... > > Mike McCandless > > http://blog.mikemccandless.com > > > On Sun, Dec 2, 2012 at 5:53 PM, Policeman Jenkins Server > wrote: >> Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/3026/ >> Java: 32bit/jdk1.7.0_09 -server -XX:+UseParallelGC >> >> All tests passed >> >> Build Log: >> [...truncated 25027 lines...] >> BUILD FAILED >> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:60: The >> following error occurred while executing this line: >> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:285: The >> following error occurred while executing this line: >> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1526: >> The following error occurred while executing this line: >> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1560: >> Compile failed; see the compiler error output for details. >> >> Total time: 28 minutes 52 seconds >> Build step 'Invoke Ant' marked build as failure >> Archiving artifacts >> Recording test results >> Description set: Java: 32bit/jdk1.7.0_09 -server -XX:+UseParallelGC >> Email was triggered for: Failure >> Sending email for trigger: Failure >> >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
Woops, I committed a fix ... Mike McCandless http://blog.mikemccandless.com On Sun, Dec 2, 2012 at 5:53 PM, Policeman Jenkins Server wrote: > Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/3026/ > Java: 32bit/jdk1.7.0_09 -server -XX:+UseParallelGC > > All tests passed > > Build Log: > [...truncated 25027 lines...] > BUILD FAILED > /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:60: The > following error occurred while executing this line: > /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:285: The > following error occurred while executing this line: > /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1526: > The following error occurred while executing this line: > /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1560: > Compile failed; see the compiler error output for details. > > Total time: 28 minutes 52 seconds > Build step 'Invoke Ant' marked build as failure > Archiving artifacts > Recording test results > Description set: Java: 32bit/jdk1.7.0_09 -server -XX:+UseParallelGC > Email was triggered for: Failure > Sending email for trigger: Failure > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/3026/ Java: 32bit/jdk1.7.0_09 -server -XX:+UseParallelGC All tests passed Build Log: [...truncated 25027 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:60: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:285: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1526: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1560: Compile failed; see the compiler error output for details. Total time: 28 minutes 52 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 32bit/jdk1.7.0_09 -server -XX:+UseParallelGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
