[squid-dev] New patches and squid-v4

[Alex Rousskov]

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.