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 0.92 branch
Date Thu, 28 Jul 2011 18:10:11 GMT
> New issues outside the list have to collect 3 +1 from committers before going in.

Do we actually have bylaws?

Our practice is RTC with one +1 other than patch creator being sufficient for commit, and
CTR for trivial changes. I'm -1 on changing this.

Hadoop core recently ran a vote to increase the threshold for RTC to three +1s for commits
that represent a branch merge. I support this for HBase. So if people think some big "new
issue" needs additional review, then we make a feature branch for it and require three +1s
for merge commit.

Best regards,

   - Andy

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

>From: Stack <stack@duboce.net>
>To: dev@hbase.apache.org
>Sent: Thursday, July 28, 2011 10:04 AM
>Subject: Re: HBase 0.92 branch
>On Thu, Jul 28, 2011 at 9:47 AM, Ted Yu <yuzhihong@gmail.com> wrote:
>> Since build 2047, TRUNK build has been on a steady decline. I believe even
>> if this trend is reversed, it is hard to guarantee that TRUNK build would be
>> healthy in the future.
>I think we can fix it.
>> Now that the issues on http://s.apache.org/x4 have come down to 18, I think
>> we should consider branching 0.92 soon (maybe after HFile v2 and HBASE-4027
>> go in and we fix the broken build).
>I suppose I'd like the issues to go to zero before we branched but I
>can go along w/ the above; if we held to my way of doing things we
>might never branch.
>> After branching, we can focus on the following:
>> 1. every checkin to 0.92 branch shouldn't break its build. This requires the
>> committer to perform at least one complete test suite run before checking
>> in.
>I'll set up a build of the branch soon as we branch.  I've been
>responsible for build breakage of late.  Will reform myself.
>> 2. patches for issues on http://s.apache.org/x4 are allowed to go into 0.92
>> branch. New issues outside the list have to collect 3 +1 from committers
>> before going in.
>I'd say 3+1s if its a 'big' change.  The small stuff should just let go through.
>Good stuff,
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message