hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: HBASE-7088 ready to commit ;)
Date Sat, 21 Dec 2013 01:03:47 GMT
On Fri, Dec 20, 2013 at 2:45 PM, Stack <stack@duboce.net> wrote:

> If you have suggestion, I'm all ears.
> Other means have been tried -- education and shaming to name two -- but
> these work sporadically if at all and even afterward, we still have
> unwanted 'testing infrastructure' committed caught only after a second
> reviewer showed up after the commit, changes to critical sections without
> proofing on 'real' cluster under 'real' loads (where the settings that work
> for unit tests, as it can be imagined, can fail miserably), and then
> incompatible changes being committed by 'veterans' even up unto recently (I
> have been guilty of all the above listed myself).

Consider reverting the substandard work more aggressively. Needing extra
friction (in the form of multiple +1s) for commit concerns me because the
bandwidth and interest of people around here I observe to be quite
variable. Same reason while I like that we have some active owners, I don't
feel we have enough coverage overall for it to work - I worry I and other
contributors will chase after people for +1s while trying to get work done.

Let's punish the few, not the whole. We should have the equivalent friction
for reverts. Reverts should work the same way as commits: propose it, get a
+1. Maintain a count of reverts by individual committer. If one or more
committers become an outlier here, the PMC can and should take action to
preserve the overall quality of the project. That can be a temporary or
permanent suspension of karma, take it up on private@ as needed.

If we do more reverting, I would suggest allowing a committer who breaks
the build the opportunity to observe the breakage and fix it. This is
normal, that's why we have the Jenkins jobs and other infrastructure set
up. It would be best to avoid it, but despite every effort sometimes it
doesn't work out, the local tests pass yet Jenkins is unhappy. Say 24 hours
because of time zone differences before it's time for someone else to step

Otherwise, unwanted 'testing infrastructure' should be reverted upon sight,
and so on, with cumulative consequences.

Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message