hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <lhofha...@yahoo.com>
Subject Re: [DISCUSSION] Policy proposal for JIRAs opened for unit test failures without patches attached
Date Thu, 08 Nov 2012 20:09:54 GMT
I'd say we keep the pressure up for failing tests... I.e. we file jiras.
IMHO, a failing test should either be fixed or disabled, otherwise it just adds noise.


(This is true for even occasionally failing tests. We have > 1000 tests, if we have many
tests that fail just once/100 runs, we get frequent build failures.)

Just my $0.02.


-- Lars



________________________________
 From: Stack <stack@duboce.net>
To: HBase Dev List <dev@hbase.apache.org> 
Sent: Thursday, November 8, 2012 11:26 AM
Subject: Re: [DISCUSSION] Policy proposal for JIRAs opened for unit test failures without
patches attached
 
On Wed, Nov 7, 2012 at 4:26 PM, Andrew Purtell <apurtell@apache.org> wrote:
> There has been a recent uptick in JIRAs opened for unit test failures
> without patches attached. Since these merely duplicate information readily
> available on our Jenkins, we should institute a policy of closing them as
> Invalid if a patch is not attached to the JIRA in a timely manner (within
> hours). Simply pointing out a failing test is not
> a consequential contribution. We should also update the How To Contribute
> documentation accordingly.
>

I can go either way.

On the one hand our JIRA has loads of issues opened against failing
tests that we need to clear up as now as either fixed, invalid, or
still pertinent.  Would be better if failing tests were just addressed
near immediately.

On the other hand, one day we'll be in a situation where we'll want to
look at tests that failed in the past but that are currently not
failing so it'd be good to keep record of the old test in JIRA.

I suppose I'd lean toward no special 'unit test' rule that precludes
creating issues for failing tests mostly because if a new user, it'd
be hard to explain the rule they'd be violating.
St.Ack
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message