Re: Branch policy question

On Sat, Mar 26, 2016 at 7:08 AM, Steve Loughran wrote: > Oh,I concur: but as we allow a single +1 for stuff done on, say, github, > we've actually got a higher standard for merging in patches from forks within > the ASF repo than there are from outside. The standard is

Re: Branch policy question

> On 24 Mar 2016, at 02:24, Chris Douglas wrote: > > CTR is- and always has been- admissible in a branch. > > On Wed, Mar 23, 2016 at 2:11 PM, Steve Loughran > wrote: >> Given that only one +1 is needed to merge a non-branch patch, he could in >>

Re: Branch policy question

Thanks Chris N for digging back on this details. The main concern on this question was started like ³Since it¹s nearly impossible for me to get timely reviews for some build and script changes Š.². So, Even for CTR process, review is needed thing at some point. I have one question here is CTR

Re: Branch policy question

CTR is- and always has been- admissible in a branch. On Wed, Mar 23, 2016 at 2:11 PM, Steve Loughran wrote: > Given that only one +1 is needed to merge a non-branch patch, he could in > theory convert the entire branch into a single .patch for review. Not that > I'd

Re: Branch policy question

Thanks for digging that up, Chris. That is completely what I would have expected but began questioning it given this thread. I think that Allen's use of a feature branch for this effort makes sense and that he should have the freedom to choose his commit policy for the branch. The tricky part

Re: Branch policy question

It's interesting to go back to the change in bylaws in 2011 that introduced the requirement for 3 binding +1s on a branch merge [1]. The text of that resolution suggests that it's supportive of commit-then-review if that's what the developers on the branch want to do. "Branches' commit

Re: Branch policy question

I think this is good technical justification for commit-then-review in a feature branch, and I would be +1 to support it. Just to briefly summarize one of my earlier comments, I see this as a way to unblock solo development work and keep it moving in parallel while rallying community members for

Re: Branch policy question

> On 22 Mar 2016, at 18:23, Andrew Wang wrote: > > A branch sounds fine, but how are we going to get 3 +1's to merge it? If > it's hard to find one reviewer, seems even harder to find two. Given that only one +1 is needed to merge a non-branch patch, he could in

Re: Branch policy question

> On 22 Mar 2016, at 16:14, Allen Wittenauer wrote: > > > Since it’s nearly impossible for me to get timely reviews for some > build and script changes, is it possible for me to setup a branch, self > review+commit to that branch, then request a branch merge? I’m

Re: Branch policy question

A feature branch seems reasonable for this work: multiple reviewable patches that are meaningful only after all of them get in. I guess most comments here that had concerns for a branch were primarily based on the initial reasoning of not being able to find a reviewer. Coming to RTC and CTR, I

Re: Branch policy question

> On Mar 23, 2016, at 10:25 AM, Chris Nauroth wrote: > > 2. Apache feature branches: Sign-off may come from designated branch > committers in addition to full committers. It's OK to break the branch > for work in progress, but it must be fixed before a merge. It's

Re: Branch policy question

> On 3/22/16, 11:03 PM, "Allen Wittenauer" > wrote: > > >> On Mar 22, 2016, at 6:46 PM, Gangumalla, Uma > >>wrote: > >> > >>> is it possible for me to setup a branch, self review+commit to that > >>> branch, then request a branch

Re: Branch policy question

It sounds like the community doesn't have a consistent point of view on the policy. Setting aside policy for a moment, I've always considered a few different branching models available when I start coding something big, with each model offering different features. 1. Apache mainline branches:

Re: Branch policy question

> On Mar 22, 2016, at 6:46 PM, Gangumalla, Uma wrote: > >> is it possible for me to setup a branch, self review+commit to that >> branch, then request a branch merge? > Basically this is something like Commit-Then-Review(here review later) > process right. I have not

Re: Branch policy question

Just to clarify, we are talking about a feature branch in which Allen and others that are working on the branch could commit without requiring 3 +1’s. Then, at some point, we will need 3 +1’s to merge the branch to trunk. Correct? I think that if we have a set of usecases that are being added and

Re: Branch policy question

> is it possible for me to setup a branch, self review+commit to that >branch, then request a branch merge? Basically this is something like Commit-Then-Review(here review later) process right. I have not seen we followed this approach here( not sure if I missed some branches followed that). Even

Re: Branch policy question

If the underlying problem is lack of reviewers for these improvements, how about a design doc giving some motivation for the improvements and explaining how they'll be implemented? Then we can decide if a branch or a few JIRAs on trunk makes more sense. The description for HADOOP-12857 is just

Re: Branch policy question

VOTE threads tend to get more eyes than random JIRAs. On Tue, Mar 22, 2016 at 1:23 PM, Andrew Wang wrote: > A branch sounds fine, but how are we going to get 3 +1's to merge it? If > it's hard to find one reviewer, seems even harder to find two. > > On Tue, Mar 22,

Re: Branch policy question

A branch sounds fine, but how are we going to get 3 +1's to merge it? If it's hard to find one reviewer, seems even harder to find two. On Tue, Mar 22, 2016 at 10:56 AM, Allen Wittenauer < allenwittena...@yahoo.com.invalid> wrote: > > > On Mar 22, 2016, at 10:49 AM, larry mccay

Re: Branch policy question

> On Mar 22, 2016, at 10:49 AM, larry mccay wrote: > > That sounds like a reasonable approach and valid use of branches to me. > > Perhaps a set of functional tests could be provided/identified that would > help the review process by showing backward compatibility along

Re: Branch policy question

That sounds like a reasonable approach and valid use of branches to me. Perhaps a set of functional tests could be provided/identified that would help the review process by showing backward compatibility along with new extensions for things like dynamic commands? On Tue, Mar 22, 2016 at 12:14

Branch policy question

Since it’s nearly impossible for me to get timely reviews for some build and script changes, is it possible for me to setup a branch, self review+commit to that branch, then request a branch merge? I’m basically looking at doing this for HADOOP-12857 + HADOOP-12930 and their subtasks