I do not think it is a big deal to force the base branch for a PR. You are free to choose the way you like, just tell users which branch to use when creating a PR.
In ASF, like Hadoop and HBase, maser is the dev branch and by default all PR must be created against the master branch. There are users open a PR against other branches, then we just tell them to open a new PR against master, and close the current one (and for hadoop, the 'master' branch is actually called 'trunk'...). And IIRC, there are other projects in the ASF want user to open PR against the current release branch, and the commiters will cherry-pick the commit back to master branch. Of course sometimes the user will just leave and not open the PR as his/her code base is not against the master branch and he/she do not want to spend much time on porting, that's fine. This is open source, people come and go. In general, just start a vote and let PPMC decided the branching strategy. And do we have a wiki page to record the discussion result? I think we'd better reach agreement step by step, and this is good sign to the IPMC, that we are making progress. For other things, like whether we should squash all the commits in a PR into one when merging, or there are dependencis between PRs, we can discuess them in another thread. Thanks. Brennan Ashton <bash...@brennanashton.com> 于2019年12月25日周三 上午8:05写道： > On Tue, Dec 24, 2019, 3:13 PM Gregory Nutt <spudan...@gmail.com> wrote: > > > > > > > > >> If they are related / dependent on each other, then I think those > > >> kinds of patchsets should be encapsulated in one branch. > > > > > > The need to be applied and committed in sequence. Sometimes the final > > > patch is the one that fixes the coding style. This is inherently very > > > manual. > > They need to be merged separately too since the author is often > > different on each patch. > > > > Why does the authors matter. There is no reason a patchset or PR needs to > be squashed into a single commit, they just should not be broken along the > way. > > Also order in a patch set is usually defined by a number prefix for example > this is how it is defined by the Linux kernel, but is inline with most > projects that do mailing list patches. > > > https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#the-canonical-patch-format > > > There is really nothing so unique about this project that we need to get > too creative. > > --Brennan > > > >
