I didn't take the docs site into account, I will have to open another issue and hopefully it fits into an existing patrern
Eric Covener [email protected] On Mon, Oct 26, 2026, 8:46 PM Jason Lingohr <[email protected]> wrote: > Ok, thanks. > > I've just done the first docs changes post-cutover and have a question: > > 1. /docs/ on the site doesn't seem to be updating from git > > Under SVN, docs commits appeared on the site within seconds; e.g. the > Last-Modified on /docs/trunk/stopping.html is 00:30:04Z, two seconds after > Rich's commit at 00:30:02Z on 31 May. > > I pushed HTML rebuilds to trunk (90e21dde8a) and 2.4.x (e385b20d48) at > about 23:22 UTC yesterday, and over an hour later the origin is still > serving the 31 May files (it's not just varnish; a cache-busted request > gets the same thing). /docs/trunk and /docs/2.4 aren't in httpd-site, so > I'm guessing they were synced from SVN by infra and that sync hasn't been > moved to GitHub yet. Was that part of INFRA-28586, or does it need its own > ticket? > > > On 27/10/26 10:02, Eric Covener wrote: > > Yes, there are some obscure repos still in SVN, but day to day work on the > main repo with the server, docs, tests should be done in git (trunk and > 2.4.x branches) > > Eric Covener > [email protected] > > On Mon, Oct 26, 2026, 6:12 PM Jason Lingohr <[email protected]> wrote: > >> So Eric, are you saying we now commit via git for http and docs, instead >> of SVN? >> >> Or is only for trunk? >> >> >> On 27/10/26 08:48, Eric Covener wrote: >> >> Thanks to priority service from Humbedooh we are fully cut over >> andhttps://github.com/apache/httpd/tree/trunk is open for business. >> >> SVN will remain read-only. >> >> Summary: >> >> - Issues stay in bugzilla, wikis in confluence (to the limited extent we use >> it) >> - Committers should see the merge button now in the github PR UI (and >> a close button which many of us did not see before) >> - Things that are currently NOT enforced as required checks in github: >> - In all branches you _should_wait for CI to complete and assess the >> result. >> - In 2.4.x: the same CTR rules (and exceptions) apply as in >> subversion but using PR reviews instead of STATUS. This is not >> currently an enforced check in github. >> - Tracking of out of date translations is broken due to the dependency >> on SVN keyword expansion. >> >> Some relatively obscure parts of the website probably need updates. >> >> On Mon, Oct 26, 2026 at 4:40 PM Jim Jagielski <[email protected]> >> <[email protected]> wrote: >> >> w00t w00t! >> >> On Oct 26, 2026, at 4:30 PM, Eric Covener <[email protected]> >> <[email protected]> wrote: >> >> The release scripts are ready and validated as much as possible on a fork. >> We also have a candidate/initial .asf.yaml (Thanks Joe!) -- getting >> required reviews on 2.4.x will initially not be enforced (double edged >> sword: it helps the release process and CTR of special stuff) >> >> The infra ticket is here for anyone who wants to >> follow:https://issues.apache.org/jira/browse/INFRA-28586 >> >> >> >> >> >> On Mon, Oct 19, 2026 at 4:26 AM Jim Jagielski <[email protected]> >> <[email protected]> wrote: >> >> >> Thanks for prodding this... I still support the effort and offer to help >> with whatever grunt work may arise. >> >> On Oct 18, 2026, at 9:51 AM, Eric Covener <[email protected]> >> <[email protected]> wrote: >> >> I have been thinking of coming back to this and working on the release >> process aspect. Once it looks reasonably in hand against a fork I'd >> like to move forward and maybe cut a low-stakes / non security >> release. >> >> I wanted to give folks one more chance to raise any blockers/concerns, >> either inline here or in the cwiki below: >> https://cwiki.apache.org/confluence/spaces/HTTPD/pages/311628229/Read+Write+git+migration >> >> >> On Tue, Aug 20, 2024 at 3:52 AM Ruediger Pluem <[email protected]> >> <[email protected]> wrote: >> >> >> >> >> On 8/19/24 7:44 PM, Roy T. Fielding wrote: >> >> On Aug 19, 2024, at 8:22 AM, Eric Covener <[email protected]> >> <[email protected]> wrote: >> >> To bring the convo back here out of cwiki -- in a world where we moved >> to read/write git, with reviews happening in the context of a pull >> request, does anyone else have any feelings about ditching or keeping >> the STATUS file? >> >> >> I created STATUS to help drive dev conversations toward a release. >> A resource-based window on open issues, organized by tag or priority, >> would be just as good and easier to maintain. +1 to a replacement. >> >> I suggest leaving STATUS as a static file containing a link to the new >> resource >> and maybe examples of using the GH API to download a local copy of issues. >> >> >> Let's try this. If it does not work out we just change it to something else >> that works better. >> >> Regards >> >> Rüdiger >> >> >> >> -- >> Eric [email protected] >> >> >> -- >> Jim >> "This is an outrage!" >> Tony Harrison >> >> >> >> -- >> Eric [email protected] >> >> >> -- >> Jim >> "This is an outrage!" >> Tony Harrison >> >> >>
