Re: mod_http2/mod_md upkeep

"Stefan Eissing via dev" <[email protected]> Tue, 9 Jun 2026 11:02:28 +0200
Newsgroups gmane.comp.apache.devel
Message-ID <[email protected]>
FYI: I archived the github mod_h2 and mod_md repositories.

- Stefan

> Am 05.06.2026 um 18:40 schrieb Stefan Eissing via dev =
<[email protected]>:
>=20
>=20
>=20
>> Am 05.06.2026 um 18:31 schrieb Joe Orton <[email protected]>:
>>=20
>> On Fri, Jun 05, 2026 at 02:48:14PM +0200, Stefan Eissing via dev =
wrote:
>>> =46rom 2.4.x STATUS: "I guess Stefan will take care."
>>>=20
>>> FYI: Stefan is totally under water and has been for months now, curl =
being the first project to be hit by the LLM craziness.
>>>=20
>>> I have in the past silently synched changes between the repositories =
for people who drop things into trunk and never proposing backports or =
compatibility with 2.4.x. That service I can no longer do. If you change =
anything in mod_http2 or mod_md, it's now your task to do this.
>>>=20
>>> For me "trunk" is a graveyard and an obstacle, a necessary evil for =
maintaining 2.4.x. This might sound harsh to some, but the last decade =
has only confirmed this as a reality (I expressed this in the past). I =
can only regard the recent uptick in trunk changes as going in a =
direction I am no longer able (as in having the mental strength and =
time) to follow.=20
>>>=20
>>> If there is something puzzling in the modules' code, please contact =
me=20
>>> and I am happy to help. But I have to step back from the daily=20
>>> security list madness and the tidy up work. At some point, it will=20=

>>> probably be best to set the github modules repository to archive =
mode.
>>=20
>> Thanks Stefan, and totally understand.
>>=20
>> We discussed in the PR and on slack a bit. If we move to r/w git, we=20=

>> could import mod_h2 via a git submodule which would force people to=20=

>> submit/propose changes there (or at least prevent change in svn trunk=20=

>> directly). That would avoid the overhead of maintaining the code in =
two=20
>> places.
>=20
> I do not recommend this, as you can see from your PR #331 and the =
difficulty of having code that works in trunk and 2.4.x.
>=20
> The problems are inherent in the way the project handles its branches.
>=20
> I am a bit foul-mouthed today (which gets the more attractive the more =
pieces of LLM novellas one encounters), but "trunk" is and for the last =
decade has been a kind of LALA-land, where on can commit =
well-intentioned changes without ever having to maintain them in the =
real world. The maintainers of 2.4.x have to carefully work around that, =
spending extra cycles to keep this dreamland going.
>=20
> The branch policy made sense at then time when 2.4.x was exptected to =
be short-lived and a 2.6 or whatever coming Real Soon Now. There is no =
evidence that it will arrive. It is what it is.
>=20
>> In the meantime I got Claude to create=20
>> =
https://svn.apache.org/repos/asf/httpd/dev-tools/trunk/github/mod_h2_sync_=
from_trunk.sh
>> to help us create icing/mod_h2 MRs out of trunk changes> I encourage=20=

>> other httpd committers to use that or do it manualy, if you want to=20=

>> touch modules/http2. Will adapt for mod_md as well if I get a second=20=

>> next week.
>=20
> I do not want to put workload on the other people in the project. Atm, =
I favour putting the github repositories into archive mode. Which is =
then also clear to everyone visiting and avoids explaining this to =
people having issues or PRs.
>=20
> Regards,
> Stefan
>=20
>>=20
>> Regards, Joe