Re: backports
> On Mar 4, 2022, at 6:17 AM, Eric Covener wrote: > > On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski wrote: >> >> A question: Would it be easier for all this if we moved to being Github >> canon? > > I think it is much more straightforward. The original work, reviews > and travis results are all in the same place and nothing is copied > around. > I have had the same thought a few times this week. But I was hesitant > to reopen that thread/discussion because I'm pessimistic we can get > anywhere on it. I think we are far beyond that point where staying with svn/bugzilla is actively hurting the project for little or no benefit. I'd +1 a switch just to get real issue management and PRs. Roy
Re: backports
On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski wrote: > > A question: Would it be easier for all this if we moved to being Github canon? I think it is much more straightforward. The original work, reviews and travis results are all in the same place and nothing is copied around. I have had the same thought a few times this week. But I was hesitant to reopen that thread/discussion because I'm pessimistic we can get anywhere on it.
Re: backports
A question: Would it be easier for all this if we moved to being Github canon? > On Mar 4, 2022, at 5:08 AM, Stefan Eissing wrote: > > We should improve our backport procedure and provide guidance on how to use > it after the next release. > > Post-mortem dbm backport: > - the patch pointed to the in 2.4.x/STATUS was incomplete, lacking APLOGNO() > - the incomplete patch was voted on and accepted, as local tests do not have > the full CI checks > - Jim applied the voted on backport patch > - CI failed > No one did anything really wrong. We did just not apply the CI tools > available until the damage was done. > > As noted in the related thread, backport proposal should really be PRs on > github. Those are checked by > our CI and a PR can easily be improved by adding submits to the branch it is > based on. In addition, we > get the github UI for review and comments. Should be a win for all. > > Kind Regards, > Stefan > >
Re: svn commit: r1898586 - in /httpd/httpd/branches/2.4.x: ./ changes-entries/pr65881.txt modules/http2/h2_request.c test/modules/http2/env.py test/modules/http2/htdocs/cgi/hello.py test/modules/http2
> Am 04.03.2022 um 11:09 schrieb Ruediger Pluem :
>
>
>
> On 3/4/22 10:50 AM, Stefan Eissing wrote:
>>
>>
>>> Am 04.03.2022 um 10:22 schrieb Ruediger Pluem :
>>>
>>>
>>>
>>> On 3/4/22 9:51 AM, ic...@apache.org wrote:
Author: icing
Date: Fri Mar 4 08:51:47 2022
New Revision: 1898586
URL: http://svn.apache.org/viewvc?rev=1898586=rev
Log:
merge of 1898146,1898173 from trunk:
*) mod_http2: preserve the port number given in a HTTP/1.1
request that was Upgraded to HTTP/2. Fixes PR65881.
Added:
httpd/httpd/branches/2.4.x/changes-entries/pr65881.txt
- copied unchanged from r1898146,
httpd/httpd/trunk/changes-entries/pr65881.txt
httpd/httpd/branches/2.4.x/test/modules/http2/test_502_proxy_port.py
- copied unchanged from r1898146,
httpd/httpd/trunk/test/modules/http2/test_502_proxy_port.py
Modified:
httpd/httpd/branches/2.4.x/ (props changed)
httpd/httpd/branches/2.4.x/modules/http2/h2_request.c
httpd/httpd/branches/2.4.x/test/modules/http2/env.py
httpd/httpd/branches/2.4.x/test/modules/http2/htdocs/cgi/hello.py
Propchange: httpd/httpd/branches/2.4.x/
--
Merged /httpd/httpd/trunk:r1898146,1898173
Modified: httpd/httpd/branches/2.4.x/modules/http2/h2_request.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/http2/h2_request.c?rev=1898586=1898585=1898586=diff
==
--- httpd/httpd/branches/2.4.x/modules/http2/h2_request.c (original)
+++ httpd/httpd/branches/2.4.x/modules/http2/h2_request.c Fri Mar 4
08:51:47 2022
@@ -69,12 +69,25 @@ apr_status_t h2_request_rcreate(h2_reque
return APR_EINVAL;
}
-if (!ap_strchr_c(authority, ':') && r->server && r->server->port) {
-apr_port_t defport = apr_uri_port_of_scheme(scheme);
-if (defport != r->server->port) {
-/* port info missing and port is not default for scheme:
append */
-authority = apr_psprintf(pool, "%s:%d", authority,
- (int)r->server->port);
+/* The authority we carry in h2_request is the 'authority' part of
+ * the URL for the request. r->hostname has stripped any port info
that
+ * might have been present. Do we need to add it?
+ */
+if (!ap_strchr_c(authority, ':')) {
+if (r->parsed_uri.port_str) {
+/* Yes, it was there, add it again. */
+authority = apr_pstrcat(pool, authority, ":",
r->parsed_uri.port_str, NULL);
+}
+else if (!r->parsed_uri.hostname && r->server && r->server->port)
{
+/* If there was no hostname in the parsed URL, the URL was
relative.
+ * In that case, we restore port from our server->port, if it
+ * is known and not the default port for the scheme. */
+apr_port_t defport = apr_uri_port_of_scheme(scheme);
+if (defport != r->server->port) {
+/* port info missing and port is not default for scheme:
append */
+authority = apr_psprintf(pool, "%s:%d", authority,
+ (int)r->server->port);
+}
}
}
>>>
>>> Sorry for my late comment, but I think the above ignores the setting of
>>> UseCanonicalPhysicalPort and UseCanonicalName.
>>>
>>> I think we should add what is returned by ap_get_server_port in case this
>>> differs from apr_uri_port_of_scheme(scheme)
>>>
>>> I think of something like the below:
>>>
>>> Index: modules/http2/h2_request.c
>>> ===
>>> --- modules/http2/h2_request.c (revision 1898509)
>>> +++ modules/http2/h2_request.c (working copy)
>>> @@ -95,21 +95,13 @@
>>> * might have been present. Do we need to add it?
>>> */
>>>if (!ap_strchr_c(authority, ':')) {
>>> -if (r->parsed_uri.port_str) {
>>> -/* Yes, it was there, add it again. */
>>> -authority = apr_pstrcat(pool, authority, ":",
>>> r->parsed_uri.port_str, NULL);
>>> +apr_port_t defport = apr_uri_port_of_scheme(scheme);
>>> +apr_port_t port = ap_get_server_port(r);
>>> +
>>> +if (defport != port) {
>>> +/* port info missing and port is not default for scheme:
>>> append */
>>> +authority = apr_psprintf(pool, "%s:%d", authority, (int)port);
>>>}
>>> -else if (!r->parsed_uri.hostname && r->server && r->server->port) {
>>> -/* If there was no hostname in the parsed URL, the URL was
>>> relative.
>>> -
Re: svn commit: r1898586 - in /httpd/httpd/branches/2.4.x: ./ changes-entries/pr65881.txt modules/http2/h2_request.c test/modules/http2/env.py test/modules/http2/htdocs/cgi/hello.py test/modules/http2
On 3/4/22 10:50 AM, Stefan Eissing wrote:
>
>
>> Am 04.03.2022 um 10:22 schrieb Ruediger Pluem :
>>
>>
>>
>> On 3/4/22 9:51 AM, ic...@apache.org wrote:
>>> Author: icing
>>> Date: Fri Mar 4 08:51:47 2022
>>> New Revision: 1898586
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1898586=rev
>>> Log:
>>> merge of 1898146,1898173 from trunk:
>>>
>>> *) mod_http2: preserve the port number given in a HTTP/1.1
>>> request that was Upgraded to HTTP/2. Fixes PR65881.
>>>
>>>
>>> Added:
>>>httpd/httpd/branches/2.4.x/changes-entries/pr65881.txt
>>> - copied unchanged from r1898146,
>>> httpd/httpd/trunk/changes-entries/pr65881.txt
>>>httpd/httpd/branches/2.4.x/test/modules/http2/test_502_proxy_port.py
>>> - copied unchanged from r1898146,
>>> httpd/httpd/trunk/test/modules/http2/test_502_proxy_port.py
>>> Modified:
>>>httpd/httpd/branches/2.4.x/ (props changed)
>>>httpd/httpd/branches/2.4.x/modules/http2/h2_request.c
>>>httpd/httpd/branches/2.4.x/test/modules/http2/env.py
>>>httpd/httpd/branches/2.4.x/test/modules/http2/htdocs/cgi/hello.py
>>>
>>> Propchange: httpd/httpd/branches/2.4.x/
>>> --
>>> Merged /httpd/httpd/trunk:r1898146,1898173
>>>
>>> Modified: httpd/httpd/branches/2.4.x/modules/http2/h2_request.c
>>> URL:
>>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/http2/h2_request.c?rev=1898586=1898585=1898586=diff
>>> ==
>>> --- httpd/httpd/branches/2.4.x/modules/http2/h2_request.c (original)
>>> +++ httpd/httpd/branches/2.4.x/modules/http2/h2_request.c Fri Mar 4
>>> 08:51:47 2022
>>> @@ -69,12 +69,25 @@ apr_status_t h2_request_rcreate(h2_reque
>>> return APR_EINVAL;
>>> }
>>>
>>> -if (!ap_strchr_c(authority, ':') && r->server && r->server->port) {
>>> -apr_port_t defport = apr_uri_port_of_scheme(scheme);
>>> -if (defport != r->server->port) {
>>> -/* port info missing and port is not default for scheme:
>>> append */
>>> -authority = apr_psprintf(pool, "%s:%d", authority,
>>> - (int)r->server->port);
>>> +/* The authority we carry in h2_request is the 'authority' part of
>>> + * the URL for the request. r->hostname has stripped any port info that
>>> + * might have been present. Do we need to add it?
>>> + */
>>> +if (!ap_strchr_c(authority, ':')) {
>>> +if (r->parsed_uri.port_str) {
>>> +/* Yes, it was there, add it again. */
>>> +authority = apr_pstrcat(pool, authority, ":",
>>> r->parsed_uri.port_str, NULL);
>>> +}
>>> +else if (!r->parsed_uri.hostname && r->server && r->server->port) {
>>> +/* If there was no hostname in the parsed URL, the URL was
>>> relative.
>>> + * In that case, we restore port from our server->port, if it
>>> + * is known and not the default port for the scheme. */
>>> +apr_port_t defport = apr_uri_port_of_scheme(scheme);
>>> +if (defport != r->server->port) {
>>> +/* port info missing and port is not default for scheme:
>>> append */
>>> +authority = apr_psprintf(pool, "%s:%d", authority,
>>> + (int)r->server->port);
>>> +}
>>> }
>>> }
>>
>> Sorry for my late comment, but I think the above ignores the setting of
>> UseCanonicalPhysicalPort and UseCanonicalName.
>>
>> I think we should add what is returned by ap_get_server_port in case this
>> differs from apr_uri_port_of_scheme(scheme)
>>
>> I think of something like the below:
>>
>> Index: modules/http2/h2_request.c
>> ===
>> --- modules/http2/h2_request.c (revision 1898509)
>> +++ modules/http2/h2_request.c (working copy)
>> @@ -95,21 +95,13 @@
>> * might have been present. Do we need to add it?
>> */
>> if (!ap_strchr_c(authority, ':')) {
>> -if (r->parsed_uri.port_str) {
>> -/* Yes, it was there, add it again. */
>> -authority = apr_pstrcat(pool, authority, ":",
>> r->parsed_uri.port_str, NULL);
>> +apr_port_t defport = apr_uri_port_of_scheme(scheme);
>> +apr_port_t port = ap_get_server_port(r);
>> +
>> +if (defport != port) {
>> +/* port info missing and port is not default for scheme: append
>> */
>> +authority = apr_psprintf(pool, "%s:%d", authority, (int)port);
>> }
>> -else if (!r->parsed_uri.hostname && r->server && r->server->port) {
>> -/* If there was no hostname in the parsed URL, the URL was
>> relative.
>> - * In that case, we restore port from our server->port, if it
>> - * is known and not the default port for the scheme. */
>> -apr_port_t defport =
backports
We should improve our backport procedure and provide guidance on how to use it after the next release. Post-mortem dbm backport: - the patch pointed to the in 2.4.x/STATUS was incomplete, lacking APLOGNO() - the incomplete patch was voted on and accepted, as local tests do not have the full CI checks - Jim applied the voted on backport patch - CI failed No one did anything really wrong. We did just not apply the CI tools available until the damage was done. As noted in the related thread, backport proposal should really be PRs on github. Those are checked by our CI and a PR can easily be improved by adding submits to the branch it is based on. In addition, we get the github UI for review and comments. Should be a win for all. Kind Regards, Stefan
Re: svn commit: r1898586 - in /httpd/httpd/branches/2.4.x: ./ changes-entries/pr65881.txt modules/http2/h2_request.c test/modules/http2/env.py test/modules/http2/htdocs/cgi/hello.py test/modules/http2
> Am 04.03.2022 um 10:22 schrieb Ruediger Pluem :
>
>
>
> On 3/4/22 9:51 AM, ic...@apache.org wrote:
>> Author: icing
>> Date: Fri Mar 4 08:51:47 2022
>> New Revision: 1898586
>>
>> URL: http://svn.apache.org/viewvc?rev=1898586=rev
>> Log:
>> merge of 1898146,1898173 from trunk:
>>
>> *) mod_http2: preserve the port number given in a HTTP/1.1
>> request that was Upgraded to HTTP/2. Fixes PR65881.
>>
>>
>> Added:
>>httpd/httpd/branches/2.4.x/changes-entries/pr65881.txt
>> - copied unchanged from r1898146,
>> httpd/httpd/trunk/changes-entries/pr65881.txt
>>httpd/httpd/branches/2.4.x/test/modules/http2/test_502_proxy_port.py
>> - copied unchanged from r1898146,
>> httpd/httpd/trunk/test/modules/http2/test_502_proxy_port.py
>> Modified:
>>httpd/httpd/branches/2.4.x/ (props changed)
>>httpd/httpd/branches/2.4.x/modules/http2/h2_request.c
>>httpd/httpd/branches/2.4.x/test/modules/http2/env.py
>>httpd/httpd/branches/2.4.x/test/modules/http2/htdocs/cgi/hello.py
>>
>> Propchange: httpd/httpd/branches/2.4.x/
>> --
>> Merged /httpd/httpd/trunk:r1898146,1898173
>>
>> Modified: httpd/httpd/branches/2.4.x/modules/http2/h2_request.c
>> URL:
>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/http2/h2_request.c?rev=1898586=1898585=1898586=diff
>> ==
>> --- httpd/httpd/branches/2.4.x/modules/http2/h2_request.c (original)
>> +++ httpd/httpd/branches/2.4.x/modules/http2/h2_request.c Fri Mar 4
>> 08:51:47 2022
>> @@ -69,12 +69,25 @@ apr_status_t h2_request_rcreate(h2_reque
>> return APR_EINVAL;
>> }
>>
>> -if (!ap_strchr_c(authority, ':') && r->server && r->server->port) {
>> -apr_port_t defport = apr_uri_port_of_scheme(scheme);
>> -if (defport != r->server->port) {
>> -/* port info missing and port is not default for scheme: append
>> */
>> -authority = apr_psprintf(pool, "%s:%d", authority,
>> - (int)r->server->port);
>> +/* The authority we carry in h2_request is the 'authority' part of
>> + * the URL for the request. r->hostname has stripped any port info that
>> + * might have been present. Do we need to add it?
>> + */
>> +if (!ap_strchr_c(authority, ':')) {
>> +if (r->parsed_uri.port_str) {
>> +/* Yes, it was there, add it again. */
>> +authority = apr_pstrcat(pool, authority, ":",
>> r->parsed_uri.port_str, NULL);
>> +}
>> +else if (!r->parsed_uri.hostname && r->server && r->server->port) {
>> +/* If there was no hostname in the parsed URL, the URL was
>> relative.
>> + * In that case, we restore port from our server->port, if it
>> + * is known and not the default port for the scheme. */
>> +apr_port_t defport = apr_uri_port_of_scheme(scheme);
>> +if (defport != r->server->port) {
>> +/* port info missing and port is not default for scheme:
>> append */
>> +authority = apr_psprintf(pool, "%s:%d", authority,
>> + (int)r->server->port);
>> +}
>> }
>> }
>
> Sorry for my late comment, but I think the above ignores the setting of
> UseCanonicalPhysicalPort and UseCanonicalName.
>
> I think we should add what is returned by ap_get_server_port in case this
> differs from apr_uri_port_of_scheme(scheme)
>
> I think of something like the below:
>
> Index: modules/http2/h2_request.c
> ===
> --- modules/http2/h2_request.c(revision 1898509)
> +++ modules/http2/h2_request.c(working copy)
> @@ -95,21 +95,13 @@
> * might have been present. Do we need to add it?
> */
> if (!ap_strchr_c(authority, ':')) {
> -if (r->parsed_uri.port_str) {
> -/* Yes, it was there, add it again. */
> -authority = apr_pstrcat(pool, authority, ":",
> r->parsed_uri.port_str, NULL);
> +apr_port_t defport = apr_uri_port_of_scheme(scheme);
> +apr_port_t port = ap_get_server_port(r);
> +
> +if (defport != port) {
> +/* port info missing and port is not default for scheme: append
> */
> +authority = apr_psprintf(pool, "%s:%d", authority, (int)port);
> }
> -else if (!r->parsed_uri.hostname && r->server && r->server->port) {
> -/* If there was no hostname in the parsed URL, the URL was
> relative.
> - * In that case, we restore port from our server->port, if it
> - * is known and not the default port for the scheme. */
> -apr_port_t defport = apr_uri_port_of_scheme(scheme);
> -if (defport != r->server->port) {
> -/* port info missing and port is not
Re: svn commit: r1898586 - in /httpd/httpd/branches/2.4.x: ./ changes-entries/pr65881.txt modules/http2/h2_request.c test/modules/http2/env.py test/modules/http2/htdocs/cgi/hello.py test/modules/http2
On 3/4/22 9:51 AM, ic...@apache.org wrote:
> Author: icing
> Date: Fri Mar 4 08:51:47 2022
> New Revision: 1898586
>
> URL: http://svn.apache.org/viewvc?rev=1898586=rev
> Log:
> merge of 1898146,1898173 from trunk:
>
> *) mod_http2: preserve the port number given in a HTTP/1.1
> request that was Upgraded to HTTP/2. Fixes PR65881.
>
>
> Added:
> httpd/httpd/branches/2.4.x/changes-entries/pr65881.txt
> - copied unchanged from r1898146,
> httpd/httpd/trunk/changes-entries/pr65881.txt
> httpd/httpd/branches/2.4.x/test/modules/http2/test_502_proxy_port.py
> - copied unchanged from r1898146,
> httpd/httpd/trunk/test/modules/http2/test_502_proxy_port.py
> Modified:
> httpd/httpd/branches/2.4.x/ (props changed)
> httpd/httpd/branches/2.4.x/modules/http2/h2_request.c
> httpd/httpd/branches/2.4.x/test/modules/http2/env.py
> httpd/httpd/branches/2.4.x/test/modules/http2/htdocs/cgi/hello.py
>
> Propchange: httpd/httpd/branches/2.4.x/
> --
> Merged /httpd/httpd/trunk:r1898146,1898173
>
> Modified: httpd/httpd/branches/2.4.x/modules/http2/h2_request.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/http2/h2_request.c?rev=1898586=1898585=1898586=diff
> ==
> --- httpd/httpd/branches/2.4.x/modules/http2/h2_request.c (original)
> +++ httpd/httpd/branches/2.4.x/modules/http2/h2_request.c Fri Mar 4 08:51:47
> 2022
> @@ -69,12 +69,25 @@ apr_status_t h2_request_rcreate(h2_reque
> return APR_EINVAL;
> }
>
> -if (!ap_strchr_c(authority, ':') && r->server && r->server->port) {
> -apr_port_t defport = apr_uri_port_of_scheme(scheme);
> -if (defport != r->server->port) {
> -/* port info missing and port is not default for scheme: append
> */
> -authority = apr_psprintf(pool, "%s:%d", authority,
> - (int)r->server->port);
> +/* The authority we carry in h2_request is the 'authority' part of
> + * the URL for the request. r->hostname has stripped any port info that
> + * might have been present. Do we need to add it?
> + */
> +if (!ap_strchr_c(authority, ':')) {
> +if (r->parsed_uri.port_str) {
> +/* Yes, it was there, add it again. */
> +authority = apr_pstrcat(pool, authority, ":",
> r->parsed_uri.port_str, NULL);
> +}
> +else if (!r->parsed_uri.hostname && r->server && r->server->port) {
> +/* If there was no hostname in the parsed URL, the URL was
> relative.
> + * In that case, we restore port from our server->port, if it
> + * is known and not the default port for the scheme. */
> +apr_port_t defport = apr_uri_port_of_scheme(scheme);
> +if (defport != r->server->port) {
> +/* port info missing and port is not default for scheme:
> append */
> +authority = apr_psprintf(pool, "%s:%d", authority,
> + (int)r->server->port);
> +}
> }
> }
Sorry for my late comment, but I think the above ignores the setting of
UseCanonicalPhysicalPort and UseCanonicalName.
I think we should add what is returned by ap_get_server_port in case this
differs from apr_uri_port_of_scheme(scheme)
I think of something like the below:
Index: modules/http2/h2_request.c
===
--- modules/http2/h2_request.c (revision 1898509)
+++ modules/http2/h2_request.c (working copy)
@@ -95,21 +95,13 @@
* might have been present. Do we need to add it?
*/
if (!ap_strchr_c(authority, ':')) {
-if (r->parsed_uri.port_str) {
-/* Yes, it was there, add it again. */
-authority = apr_pstrcat(pool, authority, ":",
r->parsed_uri.port_str, NULL);
+apr_port_t defport = apr_uri_port_of_scheme(scheme);
+apr_port_t port = ap_get_server_port(r);
+
+if (defport != port) {
+/* port info missing and port is not default for scheme: append */
+authority = apr_psprintf(pool, "%s:%d", authority, (int)port);
}
-else if (!r->parsed_uri.hostname && r->server && r->server->port) {
-/* If there was no hostname in the parsed URL, the URL was
relative.
- * In that case, we restore port from our server->port, if it
- * is known and not the default port for the scheme. */
-apr_port_t defport = apr_uri_port_of_scheme(scheme);
-if (defport != r->server->port) {
-/* port info missing and port is not default for scheme:
append */
-authority = apr_psprintf(pool, "%s:%d", authority,
- (int)r->server->port);
-}
-}
}
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/
> Am 04.03.2022 um 09:46 schrieb Ruediger Pluem : > > > > On 3/4/22 9:24 AM, Stefan Eissing wrote: >> >> >>> Am 04.03.2022 um 08:32 schrieb Ruediger Pluem : >>> >>> >>> >>> 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/
On 3/4/22 9:24 AM, Stefan Eissing wrote: > > >> Am 04.03.2022 um 08:32 schrieb Ruediger Pluem : >> >> >> >> 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/
> Am 04.03.2022 um 08:32 schrieb Ruediger Pluem : > > > > 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
