[squid-dev] New patches and squid-v4

[Christos Tsantilas]

Στις 17/11/2017 07:45 μμ, ο 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.

I agree.
However in many cases the patches can just merged without any 
modification. A new PR in these cases may cause more load.


> 
> 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.
>