On Wed, Dec 18, 2019 at 3:51 PM David Sidrane <david.sidr...@nscdg.com> wrote: > Hi Nathan, > > Great list! > > I can +1 on most of them, but isn't correct that the PPMC will need to all > agree on these?
Hi David, Thank you. As I said, I was: > Just throwing some thoughts out here as a starting point for that > top-down discussion: In other words, I wasn't stating that any of that is decided, final, or even preliminary. I just wrote down some points in the hopes that it would help get the conversation going, as Greg suggests (correctly in my opinion) that we do before delving into git operational details. More below... > > When they wish to contribute, they can do so: > > * Via a pull request > > * Via a patch transmitted to us by some method > > Is this an ASF edict? Nope. More below... > > Regardless of the method, we would convert the pull request and/or > > patch into a form that is useful for us. For example, if we work with > > pull requests and we are given a patch, we convert the patch into a > > pull request. > > Where is the ability to have group a review? How is it done? It sounds like the general direction is to use GitHub and its mechanisms. Is that correct? If so, then that's where the group review would take place. As for patches that come by email, I suppose that whoever decides to look over a patch can make a judgement call, and if they'd like to, they can create a PR out of it. I don't think there's any formal "process" for this part, but it would be nice if they'd reply to the email to tell everyone that it has been moved to a PR and give the link to it. That should also prevent (or minimize the chance of) duplicated PRs from the same patch by multiple people. More below... > > Contributions may be based on: > > * Master. > > * Or the latest release. When contributions are based on the latest > > release, we should rebase them onto master. > > What If the fix on master? Would it need to be backported to the release? > How do you see the decision made on backports and who does this? I don't know how other projects do it but I can tell you what we do over in Subversionland. Once a release branch is formed, we never commit code changes directly to it. All fixes are committed to trunk (i.e., "master") and are backported to the branch. The decision to backport a change is made as follows (summarizing roughly): A committer nominates a commit for backport by listing it in a STATUS file. This is an ordinary text file. Other committers may vote for (or against) the backport by adding their vote to the same file. Once the requisite number of votes have accumulated with no vetoes etc., the commit is approved for backport. (While this could be done manually, we have custom tooling to assist with adding items to STATUS and voting on items, and there's a bot that runs every night, checks STATUS, and does the actual merging.) If you're interested in the details: https://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization Hope this helps, Nathan
