You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Steven A Rowe <sa...@syr.edu> on 2011/01/22 00:59:58 UTC
Hudson nightly build failures due to Clover
Clover causes Hudson nightly builds to fail intermittently. This is bad, because it looks like Lucene/Solr tests are failing when they are not. But Clover is good, so nobody wants to turn it off.
One possible solution (apologies if this has already been suggested): make new nightly Clover-only Hudson builds, and remove Clover from the existing nightly builds.
I think that would address all of the issues, wouldn't it?
Steve
Re: Hudson nightly build failures due to Clover
Posted by Uwe Schindler <uw...@thetaphi.de>.
Sorry, as I said, the last 5 builds are broken by me. and please don't bug me, Steven and me do our best to serve you good builds nightly. Also the everybody-especially-some-people-hated haven builds.
And just to mention: the last builds since Hudson upgrade did not fail because of clover, only because of my stupidness.
And by the way, you can always tell people: use the link to download artifacts from "last successful build". Where is the problem?
Uwe
"Erick Erickson" <er...@gmail.com> schrieb:
>RANT WARNING! RANT WARNING!
>
>When did Lucid enter the picture? This has nothing to do with Lucid.
>
>As you say this may all be taken care of with the new Hudson, and that
>could
>be the end of the story, hooray!!!!! I'm perfectly willing to wait and
>see
>if it settles out.
>
>What this *does* have to do with, from my perspective, is that Solr
>hasn't
>had a release in
>quite a while. There is lots of goodness in the 3_x and trunk builds.
>We see
>comments on the user's list of "get a nightly build from trunk or 3_X
>and
>try it". Which may
>be sound advice. But I can absolutely guarantee that a number of
>potential
>users take
>a single glance at the number of "failures" (even if they are bogus)
>reported on Hudson and
>immediately cross Solr off their list as far as using trunk or 3.x.
>
>It doesn't matter that 1.4.1 would report the same nonsense if it was
>continually built. It
>doesn't matter that 3.x and trunk have far better automated tests. It
>doesn't matter that
>the developers have confidence. I'm talking perception here, not
>underlying
>code quality. What matters (and I'm talking perception, remember) is
>that
>out of
>the last 10 3.x builds 6 have "failed", as have 5 of the last 10 trunk
>builds. Which makes
>it easy to dismiss and/or have an exaggerated sense of the instability
>of
>the 3_x and
>trunk builds.
>
>If there were a solution that allowed us to satisfy both the
>developers'
>needs and this
>perception, I think we should go for it.
>
>Now, it may well be that the current situation is acceptable to the
>community and that our
>story should continue to be "be patient, we'll release sometime". But
>this
>story is getting
>old(er).
>
>But please don't make the mistake of dismissing stodgy corporate
>concerns
>(and I'm
>speaking of my experience at several companies here). They may or may
>not be
>valid from a technical perspective. It may even be that stodgy
>corporations
>wouldn't
>use open source software anyway. It may be that we just don't care. I'm
>not
>in a position
>to offer any hard evidence either way. Nor, I suspect is most anyone
>else
>given the recent
>Maven kerfluffle....
>
>And I have no good response at all to the reply "Ok, wise guy, dive in
>and
>*make* a
>release happen". "I'm too busy" is a pretty lousy excuse <G>...
>
>OK, rant pretty much over. It would be an easier thing to recommend
>trunk or
>3_x if there
>were some commitment to a release date. Potential users of the newer
>branches could
>at least plan on using one of them with the expectation that the target
>would stop moving
>before their go-live date. But as it is some number of users will stay
>on
>1.4.1 for lack of
>the ability to plan.
>
>FWIW
>Erick
>
>On Sat, Jan 22, 2011 at 3:37 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
>
>> The failures from today are just test builds.
>>
>> Today also a new Hudson was installed... so please simply wait a few
>days
>> until it settles.
>>
>> If Lucid wants their customer to use nightly builds, they could setup
>ones
>> on their servers for their customers? For us Hudson mostly a test
>system to
>> check our commits. And clover is part of that.
>>
>> If somebody wants to install a trunk build, they should always svn
>checkout
>> and build themselves. Then they can even fix to specific rev no and
>can
>> always reproduce their build.
>>
>> Uwe
>>
>>
>>
>> "Erick Erickson" <er...@gmail.com> schrieb:
>>
>> >I don't know what other issues you're referring to, but please,
>please,
>> >please do whatever you can to remove "false failures". It's highly
>> >disconcerting to folks we talk to on the message boards to say
>> >"Functionality you need is in the nightly builds and you can use
>them,
>> >but
>> >just ignore the errors the build reports. Really, it's OK. Trust
>us".
>> >
>> >Putting on my corporate IT hat I'd have serious reservations about
>> >using
>> >code that looks broken all the time (even if it's "just a build
>> >artifact")...
>> >
>> >Erick
>> >
>> >On Fri, Jan 21, 2011 at 6:59 PM, Steven A Rowe <sa...@syr.edu>
>wrote:
>> >
>> >> Clover causes Hudson nightly builds to fail intermittently. This
>is
>> >bad,
>> >> because it looks like Lucene/Solr tests are failing when they are
>> >not. But
>> >> Clover is good, so nobody wants to turn it off.
>> >>
>> >> One possible solution (apologies if this has already been
>suggested):
>> >make
>> >> new nightly Clover-only Hudson builds, and remove Clover from the
>> >existing
>> >> nightly builds.
>> >>
>> >> I think that would address all of the issues, wouldn't it?
>> >>
>> >> Steve
>> >>
>>
>> --
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, 28213 Bremen
>> http://www.thetaphi.de
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Hudson nightly build failures due to Clover
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Sun, Jan 23, 2011 at 1:25 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
> Hi,
>
> As said before: There is now a new Hudson version installed and since that
> event no more Clover problems. So let's give it a few days to settle and
> find out if maybe the problem is solved. But even if it's solved, I would
> not close that Hudson Bug report, we should first ask them, if somebody can
> explain *why* its solved.
Ahhh! Sorry, I missed that. That would be awesome! (But, yes, it'd
be good to understand why it's solved...).
I will keep fingers crossed.
> About the whole bug: As there seem to be transfer errors when copying
> artifacts (like clover.xml) to the master! So I don't even trust .tar.gz
> files and would not recommend anybody to download and use them!!! It's
> better to check out and build yourself.
Apparently, basic infrastructure APIs like copying bytes across a
network or, say, copying bytes across files ;), is challenging to get
right...
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Hudson nightly build failures due to Clover
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
As said before: There is now a new Hudson version installed and since that
event no more Clover problems. So let's give it a few days to settle and
find out if maybe the problem is solved. But even if it's solved, I would
not close that Hudson Bug report, we should first ask them, if somebody can
explain *why* its solved.
About the whole bug: As there seem to be transfer errors when copying
artifacts (like clover.xml) to the master! So I don't even trust .tar.gz
files and would not recommend anybody to download and use them!!! It's
better to check out and build yourself.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Sunday, January 23, 2011 4:34 PM
> To: dev@lucene.apache.org
> Subject: Re: Hudson nightly build failures due to Clover
>
> The false failures are from this bug in Hudson (right?):
>
> http://issues.hudson-ci.org/browse/HUDSON-7836
>
> Somehow the clover XML is corrupted by Hudson...
>
> Anyway, I think we should find a workaround. In general we shouldn't let
> false failures like this make us look bad. Sure we devs inside know the
scoop
> -- ignore the failure when it says all tests passed.
> But to the outside world at first glance it makes our stability look
awful.
>
> What workarounds can we take, short of shutting off the Clover build?
>
> Mike
>
> On Sun, Jan 23, 2011 at 4:30 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> > We had no more nightly build failures since hudson update that were
> > caused by clover. The recent ones are not caused by that, they are
> > caused by a committed "nocommit" by Shaie :-)
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> >
> >> -----Original Message-----
> >> From: Mark Miller [mailto:markrmiller@gmail.com]
> >> Sent: Sunday, January 23, 2011 4:33 AM
> >> To: dev@lucene.apache.org
> >> Subject: Re: Hudson nightly build failures due to Clover
> >>
> >> Heh - I'm with you - I think it would be awesome to fix :) I think
> >> the
> > other
> >> devs think so too. I think that you prodding the issue is a smart
> >> move. We
> > do
> >> want to encourage users to use the nightlies - lets more people try
> >> out
> > Uwe's
> >> questionable code early on ;) - fake failures are a downer though -
> >> it
> > probably
> >> could easily affect how some users perceive the stableness. Though if
> >> you are that concerned, you would hopefully read the message and
> >> realize that something about the message is off - it says all tests
> >> passed. Not ideal,
> > but I
> >> wonder how much it *actually* hurts trunk/nightly use. I have not
> >> seen much mail about it yet...
> >>
> >> But then again, I work at lucid too, so I'm probably reading the same
> > script
> >> you are ;)
> >>
> >> Bottom line though - everyone knows of the problem. An acceptable
> >> solution has not yet been found it seems. I guess we are waiting for
> >> the
> > bug
> >> fix to come out. If anyone really wants it fixed before that - prob
> >> going
> > to
> >> have to put on your thinking cap and dive in with some concrete
> >> suggestions/action.
> >>
> >> - Mark
> >>
> >> On Jan 22, 2011, at 5:40 PM, Erick Erickson wrote:
> >>
> >> > RANT WARNING! RANT WARNING!
> >> >
> >> > When did Lucid enter the picture? This has nothing to do with Lucid.
> >> >
> >> > As you say this may all be taken care of with the new Hudson, and
> >> > that could be the end of the story, hooray!!!!! I'm perfectly
> >> > willing to wait
> > and
> >> see if it settles out.
> >> >
> >> > What this *does* have to do with, from my perspective, is that Solr
> >> > hasn't had a release in quite a while. There is lots of goodness in
> >> > the 3_x and trunk builds. We see comments on the user's list of
> >> > "get a nightly build from trunk or 3_X and try it". Which may be
> >> > sound advice. But I can absolutely guarantee that a number of
> >> > potential users take a single glance at the number of "failures"
> >> > (even if they are
> >> bogus) reported on Hudson and immediately cross Solr off their list
> >> as far
> > as
> >> using trunk or 3.x.
> >> >
> >> > It doesn't matter that 1.4.1 would report the same nonsense if it
> >> > was continually built. It doesn't matter that 3.x and trunk have
> >> > far better automated tests. It doesn't matter that the developers
> >> > have confidence. I'm talking perception here, not underlying code
> quality.
> >> > What matters (and I'm talking perception, remember) is that out of
> >> > the last 10 3.x builds 6 have "failed", as have 5 of the last 10
> >> > trunk builds. Which makes it easy to dismiss and/or have an
> >> > exaggerated sense
> >> of the instability of the 3_x and trunk builds.
> >> >
> >> > If there were a solution that allowed us to satisfy both the
> >> > developers' needs and this perception, I think we should go for it.
> >> >
> >> > Now, it may well be that the current situation is acceptable to the
> >> > community and that our story should continue to be "be patient,
> >> > we'll release sometime". But this story is getting old(er).
> >> >
> >> > But please don't make the mistake of dismissing stodgy corporate
> >> > concerns (and I'm speaking of my experience at several companies
> >> > here). They may or may not be valid from a technical perspective.
> >> > It may even be that stodgy corporations wouldn't use open source
> >> > software anyway. It may be that we just don't care. I'm not in a
> >> > position to offer any hard evidence either way. Nor, I suspect is
> >> > most anyone else
> >> given the recent Maven kerfluffle....
> >> >
> >> > And I have no good response at all to the reply "Ok, wise guy, dive
> >> > in and *make* a release happen". "I'm too busy" is a pretty lousy
> >> > excuse
> >> <G>...
> >> >
> >> > OK, rant pretty much over. It would be an easier thing to recommend
> >> > trunk or 3_x if there were some commitment to a release date.
> >> > Potential users of the newer branches could at least plan on using
> >> > one of them with the expectation that the target would stop moving
> >> > before their go-live date. But as it is some number of users will
> >> > stay on 1.4.1
> > for
> >> lack of the ability to plan.
> >> >
> >> > FWIW
> >> > Erick
> >> >
> >> > On Sat, Jan 22, 2011 at 3:37 PM, Uwe Schindler <uw...@thetaphi.de>
> wrote:
> >> > The failures from today are just test builds.
> >> >
> >> > Today also a new Hudson was installed... so please simply wait a
> >> > few
> > days
> >> until it settles.
> >> >
> >> > If Lucid wants their customer to use nightly builds, they could
> >> > setup
> > ones
> >> on their servers for their customers? For us Hudson mostly a test
> >> system
> > to
> >> check our commits. And clover is part of that.
> >> >
> >> > If somebody wants to install a trunk build, they should always svn
> > checkout
> >> and build themselves. Then they can even fix to specific rev no and
> >> can always reproduce their build.
> >> >
> >> > Uwe
> >> >
> >> >
> >> >
> >> > "Erick Erickson" <er...@gmail.com> schrieb:
> >> >
> >> > >I don't know what other issues you're referring to, but please,
> >> > >please, please do whatever you can to remove "false failures".
> >> > >It's highly disconcerting to folks we talk to on the message
> >> > >boards to say "Functionality you need is in the nightly builds and
> >> > >you can use them, but just ignore the errors the build reports.
Really,
> it's OK.
> >> > >Trust us".
> >> > >
> >> > >Putting on my corporate IT hat I'd have serious reservations about
> >> > >using code that looks broken all the time (even if it's "just a
> >> > >build artifact")...
> >> > >
> >> > >Erick
> >> > >
> >> > >On Fri, Jan 21, 2011 at 6:59 PM, Steven A Rowe <sa...@syr.edu>
> wrote:
> >> > >
> >> > >> Clover causes Hudson nightly builds to fail intermittently.
> >> > >> This is
> >> > >bad,
> >> > >> because it looks like Lucene/Solr tests are failing when they
> >> > >> are
> >> > >not. But
> >> > >> Clover is good, so nobody wants to turn it off.
> >> > >>
> >> > >> One possible solution (apologies if this has already been
suggested):
> >> > >make
> >> > >> new nightly Clover-only Hudson builds, and remove Clover from
> >> > >> the
> >> > >existing
> >> > >> nightly builds.
> >> > >>
> >> > >> I think that would address all of the issues, wouldn't it?
> >> > >>
> >> > >> Steve
> >> > >>
> >> >
> >> > --
> >> > Uwe Schindler
> >> > H.-H.-Meier-Allee 63, 28213 Bremen
> >> > http://www.thetaphi.de
> >> >
> >> > -------------------------------------------------------------------
> >> > -- To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> >> > additional commands, e-mail: dev-help@lucene.apache.org
> >> >
> >> >
> >>
> >> - Mark Miller
> >> lucidimagination.com
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> >> additional commands, e-mail: dev-help@lucene.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> > additional commands, e-mail: dev-help@lucene.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Hudson nightly build failures due to Clover
Posted by Michael McCandless <lu...@mikemccandless.com>.
The false failures are from this bug in Hudson (right?):
http://issues.hudson-ci.org/browse/HUDSON-7836
Somehow the clover XML is corrupted by Hudson...
Anyway, I think we should find a workaround. In general we shouldn't
let false failures like this make us look bad. Sure we devs inside
know the scoop -- ignore the failure when it says all tests passed.
But to the outside world at first glance it makes our stability look
awful.
What workarounds can we take, short of shutting off the Clover build?
Mike
On Sun, Jan 23, 2011 at 4:30 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> We had no more nightly build failures since hudson update that were caused
> by clover. The recent ones are not caused by that, they are caused by a
> committed "nocommit" by Shaie :-)
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: Mark Miller [mailto:markrmiller@gmail.com]
>> Sent: Sunday, January 23, 2011 4:33 AM
>> To: dev@lucene.apache.org
>> Subject: Re: Hudson nightly build failures due to Clover
>>
>> Heh - I'm with you - I think it would be awesome to fix :) I think the
> other
>> devs think so too. I think that you prodding the issue is a smart move. We
> do
>> want to encourage users to use the nightlies - lets more people try out
> Uwe's
>> questionable code early on ;) - fake failures are a downer though - it
> probably
>> could easily affect how some users perceive the stableness. Though if you
>> are that concerned, you would hopefully read the message and realize that
>> something about the message is off - it says all tests passed. Not ideal,
> but I
>> wonder how much it *actually* hurts trunk/nightly use. I have not seen
>> much mail about it yet...
>>
>> But then again, I work at lucid too, so I'm probably reading the same
> script
>> you are ;)
>>
>> Bottom line though - everyone knows of the problem. An acceptable
>> solution has not yet been found it seems. I guess we are waiting for the
> bug
>> fix to come out. If anyone really wants it fixed before that - prob going
> to
>> have to put on your thinking cap and dive in with some concrete
>> suggestions/action.
>>
>> - Mark
>>
>> On Jan 22, 2011, at 5:40 PM, Erick Erickson wrote:
>>
>> > RANT WARNING! RANT WARNING!
>> >
>> > When did Lucid enter the picture? This has nothing to do with Lucid.
>> >
>> > As you say this may all be taken care of with the new Hudson, and that
>> > could be the end of the story, hooray!!!!! I'm perfectly willing to wait
> and
>> see if it settles out.
>> >
>> > What this *does* have to do with, from my perspective, is that Solr
>> > hasn't had a release in quite a while. There is lots of goodness in
>> > the 3_x and trunk builds. We see comments on the user's list of "get a
>> > nightly build from trunk or 3_X and try it". Which may be sound
>> > advice. But I can absolutely guarantee that a number of potential
>> > users take a single glance at the number of "failures" (even if they are
>> bogus) reported on Hudson and immediately cross Solr off their list as far
> as
>> using trunk or 3.x.
>> >
>> > It doesn't matter that 1.4.1 would report the same nonsense if it was
>> > continually built. It doesn't matter that 3.x and trunk have far
>> > better automated tests. It doesn't matter that the developers have
>> > confidence. I'm talking perception here, not underlying code quality.
>> > What matters (and I'm talking perception, remember) is that out of the
>> > last 10 3.x builds 6 have "failed", as have 5 of the last 10 trunk
>> > builds. Which makes it easy to dismiss and/or have an exaggerated sense
>> of the instability of the 3_x and trunk builds.
>> >
>> > If there were a solution that allowed us to satisfy both the
>> > developers' needs and this perception, I think we should go for it.
>> >
>> > Now, it may well be that the current situation is acceptable to the
>> > community and that our story should continue to be "be patient, we'll
>> > release sometime". But this story is getting old(er).
>> >
>> > But please don't make the mistake of dismissing stodgy corporate
>> > concerns (and I'm speaking of my experience at several companies
>> > here). They may or may not be valid from a technical perspective. It
>> > may even be that stodgy corporations wouldn't use open source software
>> > anyway. It may be that we just don't care. I'm not in a position to
>> > offer any hard evidence either way. Nor, I suspect is most anyone else
>> given the recent Maven kerfluffle....
>> >
>> > And I have no good response at all to the reply "Ok, wise guy, dive in
>> > and *make* a release happen". "I'm too busy" is a pretty lousy excuse
>> <G>...
>> >
>> > OK, rant pretty much over. It would be an easier thing to recommend
>> > trunk or 3_x if there were some commitment to a release date.
>> > Potential users of the newer branches could at least plan on using one
>> > of them with the expectation that the target would stop moving before
>> > their go-live date. But as it is some number of users will stay on 1.4.1
> for
>> lack of the ability to plan.
>> >
>> > FWIW
>> > Erick
>> >
>> > On Sat, Jan 22, 2011 at 3:37 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
>> > The failures from today are just test builds.
>> >
>> > Today also a new Hudson was installed... so please simply wait a few
> days
>> until it settles.
>> >
>> > If Lucid wants their customer to use nightly builds, they could setup
> ones
>> on their servers for their customers? For us Hudson mostly a test system
> to
>> check our commits. And clover is part of that.
>> >
>> > If somebody wants to install a trunk build, they should always svn
> checkout
>> and build themselves. Then they can even fix to specific rev no and can
>> always reproduce their build.
>> >
>> > Uwe
>> >
>> >
>> >
>> > "Erick Erickson" <er...@gmail.com> schrieb:
>> >
>> > >I don't know what other issues you're referring to, but please,
>> > >please, please do whatever you can to remove "false failures". It's
>> > >highly disconcerting to folks we talk to on the message boards to say
>> > >"Functionality you need is in the nightly builds and you can use
>> > >them, but just ignore the errors the build reports. Really, it's OK.
>> > >Trust us".
>> > >
>> > >Putting on my corporate IT hat I'd have serious reservations about
>> > >using code that looks broken all the time (even if it's "just a build
>> > >artifact")...
>> > >
>> > >Erick
>> > >
>> > >On Fri, Jan 21, 2011 at 6:59 PM, Steven A Rowe <sa...@syr.edu> wrote:
>> > >
>> > >> Clover causes Hudson nightly builds to fail intermittently. This
>> > >> is
>> > >bad,
>> > >> because it looks like Lucene/Solr tests are failing when they are
>> > >not. But
>> > >> Clover is good, so nobody wants to turn it off.
>> > >>
>> > >> One possible solution (apologies if this has already been suggested):
>> > >make
>> > >> new nightly Clover-only Hudson builds, and remove Clover from the
>> > >existing
>> > >> nightly builds.
>> > >>
>> > >> I think that would address all of the issues, wouldn't it?
>> > >>
>> > >> Steve
>> > >>
>> >
>> > --
>> > Uwe Schindler
>> > H.-H.-Meier-Allee 63, 28213 Bremen
>> > http://www.thetaphi.de
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
>> > additional commands, e-mail: dev-help@lucene.apache.org
>> >
>> >
>>
>> - Mark Miller
>> lucidimagination.com
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
>> commands, e-mail: dev-help@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Hudson nightly build failures due to Clover
Posted by Uwe Schindler <uw...@thetaphi.de>.
We had no more nightly build failures since hudson update that were caused
by clover. The recent ones are not caused by that, they are caused by a
committed "nocommit" by Shaie :-)
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Mark Miller [mailto:markrmiller@gmail.com]
> Sent: Sunday, January 23, 2011 4:33 AM
> To: dev@lucene.apache.org
> Subject: Re: Hudson nightly build failures due to Clover
>
> Heh - I'm with you - I think it would be awesome to fix :) I think the
other
> devs think so too. I think that you prodding the issue is a smart move. We
do
> want to encourage users to use the nightlies - lets more people try out
Uwe's
> questionable code early on ;) - fake failures are a downer though - it
probably
> could easily affect how some users perceive the stableness. Though if you
> are that concerned, you would hopefully read the message and realize that
> something about the message is off - it says all tests passed. Not ideal,
but I
> wonder how much it *actually* hurts trunk/nightly use. I have not seen
> much mail about it yet...
>
> But then again, I work at lucid too, so I'm probably reading the same
script
> you are ;)
>
> Bottom line though - everyone knows of the problem. An acceptable
> solution has not yet been found it seems. I guess we are waiting for the
bug
> fix to come out. If anyone really wants it fixed before that - prob going
to
> have to put on your thinking cap and dive in with some concrete
> suggestions/action.
>
> - Mark
>
> On Jan 22, 2011, at 5:40 PM, Erick Erickson wrote:
>
> > RANT WARNING! RANT WARNING!
> >
> > When did Lucid enter the picture? This has nothing to do with Lucid.
> >
> > As you say this may all be taken care of with the new Hudson, and that
> > could be the end of the story, hooray!!!!! I'm perfectly willing to wait
and
> see if it settles out.
> >
> > What this *does* have to do with, from my perspective, is that Solr
> > hasn't had a release in quite a while. There is lots of goodness in
> > the 3_x and trunk builds. We see comments on the user's list of "get a
> > nightly build from trunk or 3_X and try it". Which may be sound
> > advice. But I can absolutely guarantee that a number of potential
> > users take a single glance at the number of "failures" (even if they are
> bogus) reported on Hudson and immediately cross Solr off their list as far
as
> using trunk or 3.x.
> >
> > It doesn't matter that 1.4.1 would report the same nonsense if it was
> > continually built. It doesn't matter that 3.x and trunk have far
> > better automated tests. It doesn't matter that the developers have
> > confidence. I'm talking perception here, not underlying code quality.
> > What matters (and I'm talking perception, remember) is that out of the
> > last 10 3.x builds 6 have "failed", as have 5 of the last 10 trunk
> > builds. Which makes it easy to dismiss and/or have an exaggerated sense
> of the instability of the 3_x and trunk builds.
> >
> > If there were a solution that allowed us to satisfy both the
> > developers' needs and this perception, I think we should go for it.
> >
> > Now, it may well be that the current situation is acceptable to the
> > community and that our story should continue to be "be patient, we'll
> > release sometime". But this story is getting old(er).
> >
> > But please don't make the mistake of dismissing stodgy corporate
> > concerns (and I'm speaking of my experience at several companies
> > here). They may or may not be valid from a technical perspective. It
> > may even be that stodgy corporations wouldn't use open source software
> > anyway. It may be that we just don't care. I'm not in a position to
> > offer any hard evidence either way. Nor, I suspect is most anyone else
> given the recent Maven kerfluffle....
> >
> > And I have no good response at all to the reply "Ok, wise guy, dive in
> > and *make* a release happen". "I'm too busy" is a pretty lousy excuse
> <G>...
> >
> > OK, rant pretty much over. It would be an easier thing to recommend
> > trunk or 3_x if there were some commitment to a release date.
> > Potential users of the newer branches could at least plan on using one
> > of them with the expectation that the target would stop moving before
> > their go-live date. But as it is some number of users will stay on 1.4.1
for
> lack of the ability to plan.
> >
> > FWIW
> > Erick
> >
> > On Sat, Jan 22, 2011 at 3:37 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
> > The failures from today are just test builds.
> >
> > Today also a new Hudson was installed... so please simply wait a few
days
> until it settles.
> >
> > If Lucid wants their customer to use nightly builds, they could setup
ones
> on their servers for their customers? For us Hudson mostly a test system
to
> check our commits. And clover is part of that.
> >
> > If somebody wants to install a trunk build, they should always svn
checkout
> and build themselves. Then they can even fix to specific rev no and can
> always reproduce their build.
> >
> > Uwe
> >
> >
> >
> > "Erick Erickson" <er...@gmail.com> schrieb:
> >
> > >I don't know what other issues you're referring to, but please,
> > >please, please do whatever you can to remove "false failures". It's
> > >highly disconcerting to folks we talk to on the message boards to say
> > >"Functionality you need is in the nightly builds and you can use
> > >them, but just ignore the errors the build reports. Really, it's OK.
> > >Trust us".
> > >
> > >Putting on my corporate IT hat I'd have serious reservations about
> > >using code that looks broken all the time (even if it's "just a build
> > >artifact")...
> > >
> > >Erick
> > >
> > >On Fri, Jan 21, 2011 at 6:59 PM, Steven A Rowe <sa...@syr.edu> wrote:
> > >
> > >> Clover causes Hudson nightly builds to fail intermittently. This
> > >> is
> > >bad,
> > >> because it looks like Lucene/Solr tests are failing when they are
> > >not. But
> > >> Clover is good, so nobody wants to turn it off.
> > >>
> > >> One possible solution (apologies if this has already been suggested):
> > >make
> > >> new nightly Clover-only Hudson builds, and remove Clover from the
> > >existing
> > >> nightly builds.
> > >>
> > >> I think that would address all of the issues, wouldn't it?
> > >>
> > >> Steve
> > >>
> >
> > --
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, 28213 Bremen
> > http://www.thetaphi.de
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> > additional commands, e-mail: dev-help@lucene.apache.org
> >
> >
>
> - Mark Miller
> lucidimagination.com
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Hudson nightly build failures due to Clover
Posted by Mark Miller <ma...@gmail.com>.
Heh - I'm with you - I think it would be awesome to fix :) I think the other devs think so too. I think that you prodding the issue is a smart move. We do want to encourage users to use the nightlies - lets more people try out Uwe's questionable code early on ;) - fake failures are a downer though - it probably could easily affect how some users perceive the stableness. Though if you are that concerned, you would hopefully read the message and realize that something about the message is off - it says all tests passed. Not ideal, but I wonder how much it *actually* hurts trunk/nightly use. I have not seen much mail about it yet...
But then again, I work at lucid too, so I'm probably reading the same script you are ;)
Bottom line though - everyone knows of the problem. An acceptable solution has not yet been found it seems. I guess we are waiting for the bug fix to come out. If anyone really wants it fixed before that - prob going to have to put on your thinking cap and dive in with some concrete suggestions/action.
- Mark
On Jan 22, 2011, at 5:40 PM, Erick Erickson wrote:
> RANT WARNING! RANT WARNING!
>
> When did Lucid enter the picture? This has nothing to do with Lucid.
>
> As you say this may all be taken care of with the new Hudson, and that could
> be the end of the story, hooray!!!!! I'm perfectly willing to wait and see if it settles out.
>
> What this *does* have to do with, from my perspective, is that Solr hasn't had a release in
> quite a while. There is lots of goodness in the 3_x and trunk builds. We see
> comments on the user's list of "get a nightly build from trunk or 3_X and try it". Which may
> be sound advice. But I can absolutely guarantee that a number of potential users take
> a single glance at the number of "failures" (even if they are bogus) reported on Hudson and
> immediately cross Solr off their list as far as using trunk or 3.x.
>
> It doesn't matter that 1.4.1 would report the same nonsense if it was continually built. It
> doesn't matter that 3.x and trunk have far better automated tests. It doesn't matter that
> the developers have confidence. I'm talking perception here, not underlying
> code quality. What matters (and I'm talking perception, remember) is that out of
> the last 10 3.x builds 6 have "failed", as have 5 of the last 10 trunk builds. Which makes
> it easy to dismiss and/or have an exaggerated sense of the instability of the 3_x and
> trunk builds.
>
> If there were a solution that allowed us to satisfy both the developers' needs and this
> perception, I think we should go for it.
>
> Now, it may well be that the current situation is acceptable to the community and that our
> story should continue to be "be patient, we'll release sometime". But this story is getting
> old(er).
>
> But please don't make the mistake of dismissing stodgy corporate concerns (and I'm
> speaking of my experience at several companies here). They may or may not be
> valid from a technical perspective. It may even be that stodgy corporations wouldn't
> use open source software anyway. It may be that we just don't care. I'm not in a position
> to offer any hard evidence either way. Nor, I suspect is most anyone else given the recent
> Maven kerfluffle....
>
> And I have no good response at all to the reply "Ok, wise guy, dive in and *make* a
> release happen". "I'm too busy" is a pretty lousy excuse <G>...
>
> OK, rant pretty much over. It would be an easier thing to recommend trunk or 3_x if there
> were some commitment to a release date. Potential users of the newer branches could
> at least plan on using one of them with the expectation that the target would stop moving
> before their go-live date. But as it is some number of users will stay on 1.4.1 for lack of
> the ability to plan.
>
> FWIW
> Erick
>
> On Sat, Jan 22, 2011 at 3:37 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
> The failures from today are just test builds.
>
> Today also a new Hudson was installed... so please simply wait a few days until it settles.
>
> If Lucid wants their customer to use nightly builds, they could setup ones on their servers for their customers? For us Hudson mostly a test system to check our commits. And clover is part of that.
>
> If somebody wants to install a trunk build, they should always svn checkout and build themselves. Then they can even fix to specific rev no and can always reproduce their build.
>
> Uwe
>
>
>
> "Erick Erickson" <er...@gmail.com> schrieb:
>
> >I don't know what other issues you're referring to, but please, please,
> >please do whatever you can to remove "false failures". It's highly
> >disconcerting to folks we talk to on the message boards to say
> >"Functionality you need is in the nightly builds and you can use them,
> >but
> >just ignore the errors the build reports. Really, it's OK. Trust us".
> >
> >Putting on my corporate IT hat I'd have serious reservations about
> >using
> >code that looks broken all the time (even if it's "just a build
> >artifact")...
> >
> >Erick
> >
> >On Fri, Jan 21, 2011 at 6:59 PM, Steven A Rowe <sa...@syr.edu> wrote:
> >
> >> Clover causes Hudson nightly builds to fail intermittently. This is
> >bad,
> >> because it looks like Lucene/Solr tests are failing when they are
> >not. But
> >> Clover is good, so nobody wants to turn it off.
> >>
> >> One possible solution (apologies if this has already been suggested):
> >make
> >> new nightly Clover-only Hudson builds, and remove Clover from the
> >existing
> >> nightly builds.
> >>
> >> I think that would address all of the issues, wouldn't it?
> >>
> >> Steve
> >>
>
> --
> Uwe Schindler
> H.-H.-Meier-Allee 63, 28213 Bremen
> http://www.thetaphi.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
- Mark Miller
lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Hudson nightly build failures due to Clover
Posted by Erick Erickson <er...@gmail.com>.
RANT WARNING! RANT WARNING!
When did Lucid enter the picture? This has nothing to do with Lucid.
As you say this may all be taken care of with the new Hudson, and that could
be the end of the story, hooray!!!!! I'm perfectly willing to wait and see
if it settles out.
What this *does* have to do with, from my perspective, is that Solr hasn't
had a release in
quite a while. There is lots of goodness in the 3_x and trunk builds. We see
comments on the user's list of "get a nightly build from trunk or 3_X and
try it". Which may
be sound advice. But I can absolutely guarantee that a number of potential
users take
a single glance at the number of "failures" (even if they are bogus)
reported on Hudson and
immediately cross Solr off their list as far as using trunk or 3.x.
It doesn't matter that 1.4.1 would report the same nonsense if it was
continually built. It
doesn't matter that 3.x and trunk have far better automated tests. It
doesn't matter that
the developers have confidence. I'm talking perception here, not underlying
code quality. What matters (and I'm talking perception, remember) is that
out of
the last 10 3.x builds 6 have "failed", as have 5 of the last 10 trunk
builds. Which makes
it easy to dismiss and/or have an exaggerated sense of the instability of
the 3_x and
trunk builds.
If there were a solution that allowed us to satisfy both the developers'
needs and this
perception, I think we should go for it.
Now, it may well be that the current situation is acceptable to the
community and that our
story should continue to be "be patient, we'll release sometime". But this
story is getting
old(er).
But please don't make the mistake of dismissing stodgy corporate concerns
(and I'm
speaking of my experience at several companies here). They may or may not be
valid from a technical perspective. It may even be that stodgy corporations
wouldn't
use open source software anyway. It may be that we just don't care. I'm not
in a position
to offer any hard evidence either way. Nor, I suspect is most anyone else
given the recent
Maven kerfluffle....
And I have no good response at all to the reply "Ok, wise guy, dive in and
*make* a
release happen". "I'm too busy" is a pretty lousy excuse <G>...
OK, rant pretty much over. It would be an easier thing to recommend trunk or
3_x if there
were some commitment to a release date. Potential users of the newer
branches could
at least plan on using one of them with the expectation that the target
would stop moving
before their go-live date. But as it is some number of users will stay on
1.4.1 for lack of
the ability to plan.
FWIW
Erick
On Sat, Jan 22, 2011 at 3:37 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
> The failures from today are just test builds.
>
> Today also a new Hudson was installed... so please simply wait a few days
> until it settles.
>
> If Lucid wants their customer to use nightly builds, they could setup ones
> on their servers for their customers? For us Hudson mostly a test system to
> check our commits. And clover is part of that.
>
> If somebody wants to install a trunk build, they should always svn checkout
> and build themselves. Then they can even fix to specific rev no and can
> always reproduce their build.
>
> Uwe
>
>
>
> "Erick Erickson" <er...@gmail.com> schrieb:
>
> >I don't know what other issues you're referring to, but please, please,
> >please do whatever you can to remove "false failures". It's highly
> >disconcerting to folks we talk to on the message boards to say
> >"Functionality you need is in the nightly builds and you can use them,
> >but
> >just ignore the errors the build reports. Really, it's OK. Trust us".
> >
> >Putting on my corporate IT hat I'd have serious reservations about
> >using
> >code that looks broken all the time (even if it's "just a build
> >artifact")...
> >
> >Erick
> >
> >On Fri, Jan 21, 2011 at 6:59 PM, Steven A Rowe <sa...@syr.edu> wrote:
> >
> >> Clover causes Hudson nightly builds to fail intermittently. This is
> >bad,
> >> because it looks like Lucene/Solr tests are failing when they are
> >not. But
> >> Clover is good, so nobody wants to turn it off.
> >>
> >> One possible solution (apologies if this has already been suggested):
> >make
> >> new nightly Clover-only Hudson builds, and remove Clover from the
> >existing
> >> nightly builds.
> >>
> >> I think that would address all of the issues, wouldn't it?
> >>
> >> Steve
> >>
>
> --
> Uwe Schindler
> H.-H.-Meier-Allee 63, 28213 Bremen
> http://www.thetaphi.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Hudson nightly build failures due to Clover
Posted by Uwe Schindler <uw...@thetaphi.de>.
The failures from today are just test builds.
Today also a new Hudson was installed... so please simply wait a few days until it settles.
If Lucid wants their customer to use nightly builds, they could setup ones on their servers for their customers? For us Hudson mostly a test system to check our commits. And clover is part of that.
If somebody wants to install a trunk build, they should always svn checkout and build themselves. Then they can even fix to specific rev no and can always reproduce their build.
Uwe
"Erick Erickson" <er...@gmail.com> schrieb:
>I don't know what other issues you're referring to, but please, please,
>please do whatever you can to remove "false failures". It's highly
>disconcerting to folks we talk to on the message boards to say
>"Functionality you need is in the nightly builds and you can use them,
>but
>just ignore the errors the build reports. Really, it's OK. Trust us".
>
>Putting on my corporate IT hat I'd have serious reservations about
>using
>code that looks broken all the time (even if it's "just a build
>artifact")...
>
>Erick
>
>On Fri, Jan 21, 2011 at 6:59 PM, Steven A Rowe <sa...@syr.edu> wrote:
>
>> Clover causes Hudson nightly builds to fail intermittently. This is
>bad,
>> because it looks like Lucene/Solr tests are failing when they are
>not. But
>> Clover is good, so nobody wants to turn it off.
>>
>> One possible solution (apologies if this has already been suggested):
>make
>> new nightly Clover-only Hudson builds, and remove Clover from the
>existing
>> nightly builds.
>>
>> I think that would address all of the issues, wouldn't it?
>>
>> Steve
>>
--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Hudson nightly build failures due to Clover
Posted by Erick Erickson <er...@gmail.com>.
I don't know what other issues you're referring to, but please, please,
please do whatever you can to remove "false failures". It's highly
disconcerting to folks we talk to on the message boards to say
"Functionality you need is in the nightly builds and you can use them, but
just ignore the errors the build reports. Really, it's OK. Trust us".
Putting on my corporate IT hat I'd have serious reservations about using
code that looks broken all the time (even if it's "just a build
artifact")...
Erick
On Fri, Jan 21, 2011 at 6:59 PM, Steven A Rowe <sa...@syr.edu> wrote:
> Clover causes Hudson nightly builds to fail intermittently. This is bad,
> because it looks like Lucene/Solr tests are failing when they are not. But
> Clover is good, so nobody wants to turn it off.
>
> One possible solution (apologies if this has already been suggested): make
> new nightly Clover-only Hudson builds, and remove Clover from the existing
> nightly builds.
>
> I think that would address all of the issues, wouldn't it?
>
> Steve
>