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