You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joe Orton <jo...@redhat.com> on 2022/03/03 15:49:43 UTC
Re: svn commit: r1898566 - in /httpd/httpd/branches/2.4.x: ./ modules/aaa/ modules/cache/ modules/dav/fs/ modules/dav/lock/ modules/mappers/ modules/proxy/
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.
Regards, Joe
Re: svn commit: r1898566 - in /httpd/httpd/branches/2.4.x: ./ modules/aaa/ modules/cache/ modules/dav/fs/ modules/dav/lock/ modules/mappers/ modules/proxy/
Posted by Ruediger Pluem <rp...@apache.org>.
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
Re: svn commit: r1898566 - in /httpd/httpd/branches/2.4.x: ./ modules/aaa/ modules/cache/ modules/dav/fs/ modules/dav/lock/ modules/mappers/ modules/proxy/
Posted by Jim Jagielski <ji...@jaguNET.com>.
Do we have a users guide for this specific implementation and setup? TIA!
Cheers
Re: svn commit: r1898566 - in /httpd/httpd/branches/2.4.x: ./ modules/aaa/ modules/cache/ modules/dav/fs/ modules/dav/lock/ modules/mappers/ modules/proxy/
Posted by Stefan Eissing <st...@eissing.org>.
> Am 04.03.2022 um 09:46 schrieb Ruediger Pluem <rp...@apache.org>:
>
>
>
> On 3/4/22 9:24 AM, Stefan Eissing wrote:
>>
>>
>>> Am 04.03.2022 um 08:32 schrieb Ruediger Pluem <rp...@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
Re: svn commit: r1898566 - in /httpd/httpd/branches/2.4.x: ./ modules/aaa/ modules/cache/ modules/dav/fs/ modules/dav/lock/ modules/mappers/ modules/proxy/
Posted by Ruediger Pluem <rp...@apache.org>.
On 3/4/22 9:24 AM, Stefan Eissing wrote:
>
>
>> Am 04.03.2022 um 08:32 schrieb Ruediger Pluem <rp...@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
Re: svn commit: r1898566 - in /httpd/httpd/branches/2.4.x: ./ modules/aaa/ modules/cache/ modules/dav/fs/ modules/dav/lock/ modules/mappers/ modules/proxy/
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Mar 04, 2022 at 09:24:37AM +0100, Stefan Eissing wrote:
> > Am 04.03.2022 um 08:32 schrieb Ruediger Pluem <rp...@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
Re: svn commit: r1898566 - in /httpd/httpd/branches/2.4.x: ./ modules/aaa/ modules/cache/ modules/dav/fs/ modules/dav/lock/ modules/mappers/ modules/proxy/
Posted by Stefan Eissing <st...@eissing.org>.
> Am 04.03.2022 um 08:32 schrieb Ruediger Pluem <rp...@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
Re: svn commit: r1898566 - in /httpd/httpd/branches/2.4.x: ./ modules/aaa/ modules/cache/ modules/dav/fs/ modules/dav/lock/ modules/mappers/ modules/proxy/
Posted by Ruediger Pluem <rp...@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-*.
Regards
Rüdiger
Re: svn commit: r1898566 - in /httpd/httpd/branches/2.4.x: ./ modules/aaa/ modules/cache/ modules/dav/fs/ modules/dav/lock/ modules/mappers/ modules/proxy/
Posted by Joe Orton <jo...@redhat.com>.
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
Re: svn commit: r1898566 - in /httpd/httpd/branches/2.4.x: ./ modules/aaa/ modules/cache/ modules/dav/fs/ modules/dav/lock/ modules/mappers/ modules/proxy/
Posted by Ruediger Pluem <rp...@apache.org>.
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