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: Review then commit. Sign-off required from a full committer. Check the pre-commit results. Don't break the build. Strive to keep the branch shippable. 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 still review then commit though. 3. Personal GitHub repos: Commit as much as you want with no consequences. Great for speculative coding before requesting a full review, and great for staging a sequence of dependent patches. This is not visible to the Apache community though, so you run the risk of needing to toss a bunch of work later if someone objects to the changes for fundamental design reasons. Allen, are there particular reasons that you favor #2 (but with commit-then-review) instead of #3 for your work on HADOOP-12857 and HADOOP-12930? Maybe you want the patches on Apache infrastructure so you can get the pre-commit sign-offs quickly? Is it something else? I think the spirit of feature branches is to provide a more rapid development path for larger efforts. As such, I'd have no objection to allowing commit-then-review on feature branches if there is a good reason for it. By definition, a feature branch is isolated from the shipping branches, so there is no risk of harming a release. If community members are asking for design documentation and efforts to rally more people to look at the changes, then that needs to be addressed to the community's satisfaction too. (Personally, I think design documents are more heavy-weight of a process than required for these changes, but others might legitimately think differently.) If this isn't addressed, then your obstacles on this work are just deferred to merge time. Allowing commit-then-review might allow the dev work to continue in parallel while doing this though. --Chris Nauroth On 3/22/16, 11:03 PM, "Allen Wittenauer" <allenwittena...@yahoo.com.INVALID> wrote: > >> On Mar 22, 2016, at 6:46 PM, Gangumalla, Uma <uma.ganguma...@intel.com> >>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 seen we followed this approach here( not sure >>if >> I missed some branches followed that). > > At least in recent times, YARN-3368 attempted to do that with the merge >request found in YARN-4734. The first or second commit that went into >that branch clearly has never been reviewed by another committer. Since >a PMC member did the commit and merge request, I thought I¹d ask since it >implies that the policy really is CTR for merge requests. (FWIW, I was >the lone -1 on the merge request, otherwise it likely would have gone in >given it already had 2 +1¹s despite a) breaking the build b) having >significant license issues and c) no design doc.) > >
