> Am 04.03.2022 um 08:32 schrieb Ruediger Pluem <[email protected]>:
>
>
>
> On 3/3/22 5:40 PM, Joe Orton wrote:
>> On Thu, Mar 03, 2022 at 05:11:52PM +0100, Ruediger Pluem wrote:
>>> On 3/3/22 4:49 PM, Joe Orton wrote:
>>>> Folks (in no way pointing a finger at Jim who just did merging duty), it
>>>> is not hard to test your backport proposals, either in an SVN branch or
>>>> a github PR if you want better testing coverage before you submit for
>>>> review.
>>>
>>> A quick question on this. If I branch 2.4.x
>>>
>>> 1. Travis will run at all (because their is a .travis.yml in that branch)?
>>
>> Yup, Travis will definitely run for all branches, e.g. it works for the
>> candidate-2.4.x branches:
>>
>> https://app.travis-ci.com/github/apache/httpd/branches
>>
>>> 2. But the conditions in .travis.yml will likely not cause travis to run
>>> the same tests as for 2.4.x, but likely the trunk ones,
>>> correct? Hence we need adjusted conditions in .travis.yml and we need to
>>> define some kind of naming rules for branches from
>>> trunk and 2.4.x to ensure that the correct tests and builds are running?
>>
>> Oh, good question. I'm not sure how the "branch" variable appears in an
>> arbitrary branch but it's possible we'd need to tweak the conditions
>> again, yes. If we used a naming rule of "branches/2.4.x-*" for 2.4.x
>> backports would that be reasonable? This is most common from examples
>
> Sounds reasonable, but given that for candidates we use candidate-2.4.x we
> should change this to 2.4.x-candidate if we set a
> naming convention of branches/2.4.x-*.
I can change that easily, but the pattern be better: branches/2.4.* since the
candidate carries the to be released version, not 2.4.x (the name
branches/2.4.x-candidate-2.4.54 is silly and I refuse to go there -.-)
>
> Regards
>
> Rüdiger
