Out-of-tree subsites are where? (Pipe dream)

[SamB]

What is a would-be contributor supposed to do when they want to fix an issue (say, an obsolete link, possibly even broken) in a subsite that isn't in this repository?

Specifically, I noticed some stale links on the arrows subsite, but I can't figure out what repository to write patches against.

But then, of course, I immediately started thinking about how to solve the problem in general, as one does.

I can think of two satisfactory solutions:

1. Put subsites in-tree

2. Establish a table listing where each subsite's sources live.

   The easiest way to keep such a table accurate would be to use the very same table to build the file tree for haskell.org: sure, not every subsite is going to be maintained in HTML directly, but it would be much eadier to remember to update source links if they are right next to the deployment information.

   Yes, this would be kind of disruptive: it would involve switching from subsites "pushing" changes straight to the server to a model where deployment would pull stuff from all over the place every time (not necessarily from HEAD, though), but it's pretty much inevitable that someone will forget to update the info here otherwise ... no?

   I'm imagining a YAML or TOML-based format with everything you need for both deploy and the table in README , maybe something like:

   • path where the subsite appears
   • redirect if the subsite is just a redirect
   • source with a link to a web UI for the subsite
   • deployment info, would need some flexibility:
     • git repository URL (if different from source) and branch name (if you don't just want to deploy raw HTML from head)
     • tarball URL, when a git branch is inconvenient (darcs holdouts? hg users? I guess github aren't going to tell you to knock it off if this is mostly only used by one deployment workflow, not zillions of end-user installs[^1]) [^1]: Especially after they had the gall to blame GMP's servers for not keeping up when ffmpeg-builds' github actions workflow DDoSed GMP by (intentionally) doing N clones (from scratch!) of their mercurial repository, and (accidentally) letting the workflow trigger on forks, too: see https://www.theregister.com/2023/06/28/microsofts_github_gmp_project/

   Once you have such a table, then you could either:

   1. Link to that table from README
   2. (If the machine-readable source for the table lives in this repo) use a tool to splice the table into README; in CI, verify that this has been done (and print the diff if not).

[tomjaguarpaw]

Establish a table listing where each subsite's sources live.

Is this the table you're hoping for: https://github.com/haskell-infra/www.haskell.org#subsites? But you say "Link to that table from README" which suggests you've already seen that table in the README, and it's not what you want.

Put subsites in-tree

I think this is probably the correct technical solution.

[davean]

The actual mapping is in the nix config in the ghc-servers repo. Different people have sftp upload access to various sub sites.

On Tue, Aug 15, 2023 at 3:46 PM tomjaguarpaw @.***> wrote:

Establish a table listing where each subsite's sources live.

Is this the table you're hoping for: https://github.com/haskell-infra/www.haskell.org#subsites? But you say "Link to that table from README" which suggests you've already seen that table in the README, and it's not what you want.

Put subsites in-tree

I think this is probably the correct technical solution.

— Reply to this email directly, view it on GitHub https://github.com/haskell-infra/www.haskell.org/issues/280#issuecomment-1679506600, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABZLS3LJVHKNEA3XZXXRKLXVPG2JANCNFSM6AAAAAA3RP5WDM . You are receiving this because you are subscribed to this thread.Message ID: @.***>