hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@hortonworks.com>
Subject Re: Jenkins stability and patching
Date Tue, 24 Nov 2015 10:33:13 GMT

> On 23 Nov 2015, at 21:57, Colin P. McCabe <cmccabe@apache.org> wrote:
> 
> On Mon, Nov 23, 2015 at 1:53 PM, Colin P. McCabe <cmccabe@apache.org> wrote:
>> I agree that our tests are in a bad state.  It would help if we could
>> maintain a list of "flaky tests" somewhere in git and have Yetus
>> consider the flakiness of a test before -1ing a patch.  Right now, we
>> pretty much all have that list in our heads, and we're not applying it
>> very consistently.  Having this list would also let us know where to
>> concentrate our efforts to fix things.
>> 
>> On Sun, Nov 22, 2015 at 4:21 AM, Steve Loughran <stevel@hortonworks.com> wrote:
>>> 
>>> Jenkins is pretty much dead in the water these days; a test run that works is
a rare miracle rather than the default state. Which also means most patches are being +1'd
in even though patches are failing, with comments like "the test failures are probably unrelated"
>>> 
>>> 
>>> I think everyone has to be grateful that I'm not volunteering to be release manager
for 2.8, as if I were i'd have already imposed a block on any patches going in until jenkins
was stable. That is: nothing but test fixes would go in.
>>> 
>>> as it is, at least for the next couple of weeks, I'm going to experiment with
reverting patches which break the build. Usually those breakages are being fixed, eventually,
with followup patches. With a "patches which break the build get reverted" policy, whoever
submitted that first patch gets to write the fix *and test it again*. This should encourage
people to be more rigorous first time round.
>>> 
>>> 
>>>  1.  Yes, I'm going to have to be ruthless and do this for myself too. Or others
can. I'm not doing much (any?) core hadoop coding right now, so more isolated.
>>>  2.  No, I don't plan to show favouritism: break the build and it gets rolled
back.
>>>  3.  We can review this in a week or two  to see how it goes. And someone else
can volunteer to keep jenkins happy.
>>>  4.  I'll get a smaller fix for HDFS-9263 in.
>>>  5.  I've also started running slider 0.90-SNAPSHOT test runs with Hadoop 2.8.0-SNAPSHOT,
so I'm being the first to find problems beyond jenkins. So far HADOOP-12050 is the first blocker.
It went in in August, which shows we aren't doing enough cross-version testing beyond just
Jenkins. That breakage (HADOOP-12587) is stopping my test code working against secure clusters
—if I was being really harsh I'd have reverted that too, but's been in long enough I think
a fix is probably the best solution.
>> 
>> Well, this is already directly contracting point #2, isn't it? :)
> 

yes. I'm not happy how that patch has broken some of my tests though. Reverting it would benefit
me, and I am sorely tempted, but think starting with with the recent commits is the way to
gently adopt a stricter process.

> Just to be clear, I'm not trying to imply that this was favoritism (I
> don't think it was) but just that a revert is not always the right
> solution.  A short discussion usually helps to find the right
> solution, which could be a revert, a follow-on fix, or something else;
> 
> best,
> Colin


I think if a patch that goes in immediately causes a problem then it should be rolled back.
Chris has just done that to HADOOP-12572 and the LZ4 codec upgrade; I think after a while
people will just expect that as the outcome of anything going in which turns out to have problems
in jenkins or other downstream builds and tests (and my code is all ASF code here, people
are free to check out branch develop from https://git-wip-us.apache.org/repos/asf/incubator-slider.git;
build it with -Pbranch-2 and see what happens. 

To be really ambitious, we could think about having jenkins builds for downstream projects,
the way apache gump used to do for the entire ant-based ASF stack. That still wouldn't catch
the cross-version incompatibilities that I've hit this week, but it'd catch more immediate
things like changed APIs, poms, dependencies
Mime
View raw message