On 11/17/2017 10:06 AM, Christos Tsantilas wrote: > For any mew patch, we are building a git-PR for merging it to > squid-5/master. Should we make a git-PR for squid-4 too (and squid-3.5)? > Or the squid-4 maintainer is responsible to extract the patch from > squid-5 and merge it to squid-4?
Amos is the primary decision maker on this, but I would suggest a simple procedure that mimics closely the pre-GitHub procedure: 1. The maintainer is responsible for committing backports. To get the benefits of automated testing, he or she may open GitHub PRs (one for each backported feature for each branch), but there is currently no requirement to do so. 2. Anybody can backport. The backporter can post a patch, but opening a dedicated PR (as described in #1) reduces maintainer's load and offers automated tests. Naturally, the less work the maintainer has to do and the more confidence they have in the patch, the more likely he or she will commit the backport. Thus, backporting PRs should be encouraged. 3. I failed to find a _standard_ way to do this, but backport PRs should reference the original/master commit (where available), at the bottom of the commit message. For example: ----------- Fixed %<Hs, %<pt, %<tt, %<bs calculation bugs for error responses (#90) Backports commit d81657759f3ac9f3e688b4b2e8051166a23f01e1 ----------- One alternative is to reuse a single GitHub PR for all backports, but in my experience this is difficult to do correctly. It also prohibits concurrent backports of the same feature to multiple branches. GitHub is not just designed for that AFAICT. Another alternative is to commit backported patches without a PR. Item #1 allows for that. HTH, Alex. _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev