Mailing List Archive

On 3/3/22 4:49 PM, Joe Orton wrote:
> On Thu, Mar 03, 2022 at 01:30:47PM -0000, jim@apache.org wrote:
>> Author: jim
>> Date: Thu Mar 3 13:30:46 2022
>> New Revision: 1898566
>>
>> URL: http://svn.apache.org/viewvc?rev=1898566&view=rev
>> Log:
>> dbm backport approved and merged
>
> This has broken the CI with several new warnings and empty APLOGNO()
>
> https://app.travis-ci.com/github/apache/httpd/builds/247346699
>
> 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)?
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?

Regards

Rüdiger

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
at https://svn.apache.org/repos/asf/httpd/httpd/branches/ right now.

Regards, Joe

Do we have a users guide for this specific implementation and setup? TIA!

Cheers

On 3/3/22 6:47 PM, Jim Jagielski wrote:
> Do we have a users guide for this specific implementation and setup? TIA!

Have a look here:

http://svn.apache.org/viewvc/httpd/httpd/trunk/test/README.travis?view=markup
http://svn.apache.org/viewvc/httpd/dev-tools/github/README?view=markup

Regards

Rüdiger

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

Regards

Rüdiger

> Am 04.03.2022 um 08:32 schrieb Ruediger Pluem <rpluem@apache.org>:
>
>
>
> 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

On 3/4/22 9:24 AM, Stefan Eissing wrote:
>
>
>> Am 04.03.2022 um 08:32 schrieb Ruediger Pluem <rpluem@apache.org>:
>>
>>
>>
>> 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 -.-)

Yeah, let's start a fierce naming discussion :-). No seriously: branches/2.4.* is absolutely fine for me. We just need to align
changes to the release scripts and .travis.yml.

Regards

Rüdiger

> Am 04.03.2022 um 09:46 schrieb Ruediger Pluem <rpluem@apache.org>:
>
>
>
> On 3/4/22 9:24 AM, Stefan Eissing wrote:
>>
>>
>>> Am 04.03.2022 um 08:32 schrieb Ruediger Pluem <rpluem@apache.org>:
>>>
>>>
>>>
>>> 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 -.-)
>
> Yeah, let's start a fierce naming discussion :-). No seriously: branches/2.4.* is absolutely fine for me. We just need to align
> changes to the release scripts and .travis.yml.

;-)

Will do the release script changes, when agreed upon.

>
> Regards
>
> Rüdiger

On Fri, Mar 04, 2022 at 09:24:37AM +0100, Stefan Eissing wrote:
> > Am 04.03.2022 um 08:32 schrieb Ruediger Pluem <rpluem@apache.org>:
> > On 3/3/22 5:40 PM, Joe Orton wrote:
> >> 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
> -.-)

Sounds good to me. I've changed the conditions in r1898671 to treat
anything matching "^2.4" like 2.4, matching "^candidate-2.4" is also
retained for now.

Regards, Joe