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 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/
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/
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/
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: [External] c99
Hi Jim, I read Linus' statements on it and it really had to do with a technical use case that I think this article spells out well: https://www.zdnet.com/article/linus-torvalds-prepares-to-move-the-linux-kernel-to-modern-c/ I think we need something similar. What is the reason for this change besides just modernizing? Regards, KAM On 3/3/2022 8:54 AM, Jim Jagielski wrote: RAPTOR REMARK: Alert! Please be careful! This email is from an EXTERNAL sender. Be aware of impersonation and credential theft. I'm guessing we all heard the news that Linux is switching to c99 from c89. Time for us to consider it as well? -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
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 3/3/22 4:49 PM, Joe Orton wrote: > On Thu, Mar 03, 2022 at 01:30:47PM -, j...@apache.org wrote: >> Author: jim >> Date: Thu Mar 3 13:30:46 2022 >> New Revision: 1898566 >> >> URL: http://svn.apache.org/viewvc?rev=1898566=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
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 -, j...@apache.org wrote: > Author: jim > Date: Thu Mar 3 13:30:46 2022 > New Revision: 1898566 > > URL: http://svn.apache.org/viewvc?rev=1898566=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: c99
On Thu, Mar 3, 2022 at 8:54 AM Jim Jagielski wrote: > > I'm guessing we all heard the news that Linux is switching > to c99 from c89. > > Time for us to consider it as well? I thought they were skipping over c99 and going to c11. I think httpd has an extra wrinkle with legacy OS and compiler combinations (I certainly do in the distribution I look after). It would be nice to keep it optional (like the PCRE thing) or limited to new modules or something post-2.4 but I recognize those are all kind of a lot to ask.
c99
I'm guessing we all heard the news that Linux is switching to c99 from c89. Time for us to consider it as well?
Re: intent to make a release candidate on Monday
> Am 03.03.2022 um 14:32 schrieb Jim Jagielski : > > All three promoted. I went ahead and merged the 'dbm' patch Thanks, Jim! > >> On Mar 3, 2022, at 4:37 AM, Stefan Eissing wrote: >> >> There are some important fixes pending release. Work does not appear to >> slow down in the foreseeable future, so I'd like us to make them available. >> >> Looking at 2.4.x STATUS, there are 3 backport proposals lacking 1 vote: >> - dbm: Split the loading of a dbm driver >> - mod_proxy: Bump shared worker name to 384 chars. PR 53218 >> - mod_http2: preserve the port number given in a HTTP/1.1 >> >> Maybe someone finds the time to look at those. >> >> If you see something that definitely should be in the next >> release, but lack the time to make it ready for Monday, please >> let us know and we can discuss how we can help or adjust the >> schedule. >> >> Kind Regards, >> >> Stefan >> >> >
Re: intent to make a release candidate on Monday
All three promoted. I went ahead and merged the 'dbm' patch > On Mar 3, 2022, at 4:37 AM, Stefan Eissing wrote: > > There are some important fixes pending release. Work does not appear to > slow down in the foreseeable future, so I'd like us to make them available. > > Looking at 2.4.x STATUS, there are 3 backport proposals lacking 1 vote: > - dbm: Split the loading of a dbm driver > - mod_proxy: Bump shared worker name to 384 chars. PR 53218 > - mod_http2: preserve the port number given in a HTTP/1.1 > > Maybe someone finds the time to look at those. > > If you see something that definitely should be in the next > release, but lack the time to make it ready for Monday, please > let us know and we can discuss how we can help or adjust the > schedule. > > Kind Regards, > > Stefan > >
intent to make a release candidate on Monday
There are some important fixes pending release. Work does not appear to slow down in the foreseeable future, so I'd like us to make them available. Looking at 2.4.x STATUS, there are 3 backport proposals lacking 1 vote: - dbm: Split the loading of a dbm driver - mod_proxy: Bump shared worker name to 384 chars. PR 53218 - mod_http2: preserve the port number given in a HTTP/1.1 Maybe someone finds the time to look at those. If you see something that definitely should be in the next release, but lack the time to make it ready for Monday, please let us know and we can discuss how we can help or adjust the schedule. Kind Regards, Stefan
