07:58 <pq> jrayhawk, when was the last time you accessed fdo wiki history from a device that can only show text, while not having any other way at hand? How many times a year do you do that nowadays? How likely do you think it is that you are still going to need that in the future?

07:59 <pq> maybe there is some loss there, maybe not, but it has to be weighed against the gains of making wiki contributions easier in general.

08:27 <jrayhawk> I'm not asking to prevent wiki contributions (???)

08:31 <pq> I never said you would.

08:32 <pq> I said "easier", not "possible".

08:32 <jrayhawk> I mean, I don't want to interfere with your merge workflow whatsoever.

08:33 <jrayhawk> That sounds like a great feature.

08:34 <jrayhawk> pdx.edu's basement colo is an example of a place where I can't get cell phone access and they have MAC security on all ethernet and wireless ports for which I do not have a student or staff account.

08:37 <pq> so you cannot bring your own device at all in any useful way? cannot plug it in anywhere?

08:37 <jrayhawk> That's correct.

08:39 <pq> and you routinely need the wiki history there?

08:42 <pq> If you can guess what you might need, you could clone the repos before-hand. You know you're going to go off-line.

08:44 <jrayhawk> Not routinely, that sort of thing is only necessary during emergencies, typically.

08:44 <jrayhawk> E.g. systemd failing to boot on upgrade.

09:38 <daniels> does systemd routinely delete useful information from its wiki?

10:19 <jrayhawk> pq: https://people.freedesktop.org/~jrayhawk/ikiwiki-gitlab-graceful-degradation.html https://people.freedesktop.org/~jrayhawk/ikiwiki-gitlab-graceful-degradation.patch here, you can see there are literally no tradeoffs to the edit workflow for normal users

10:22 <bentiss> jrayhawk: that is IMO *very* misleading: users will think that the sources of the wikis are still on cgit.fd.o, when they are litterally not: if someone pushes there, the sync will break and the changes will not be translated to the actual website. I am not against adding a *mirror* of the sources, but the canonical information is on the gitlab instance

10:23 <bentiss> or maybe I read it too quickly....

10:23 <jrayhawk> We can add the gitlab urls to cgit.

10:23 <jrayhawk> Which we should do regardles.

10:23 <jrayhawk> +s

10:23 <bentiss> jrayhawk: honestly, the number of time we break cgit is significant enough

10:25 <jrayhawk> I mean, you have to deal with cgit one way or another; piles of old URLs are pointing there.

10:25 <jrayhawk> It's easy enough to just remove the old git URLs from it.

10:27 <bentiss> the problems with cgit: every now and then an admin needs to kick the servers because that's the way it is. The sync happends on a gitlab server hook side, and we are not really monitoring it. If we have to move the repo internally on gitlab, we have to update the hooks too, which we tend to forget

10:27 <bentiss> which means, there is a high chance the cgit trees are out of sync with the gitlab ones, and this leads to false history for you :(

10:30 <jrayhawk> Yeah, it would've been nice if jrayhawkR had been added to molly when I asked for it a decade ago so I could've sorted out the ridiculous NFS problems, but nobody seemed to interested at the time.

10:30 <bentiss> regarding cgit/gitlab sync, if it fails, we need to wait for the next commit to happen to have a sync (because we are lazy admins), which explains why the cgit trees have a high chance of being outdated

10:31 <bentiss> and last thing, I honestly believe the plan is to retire cgit once we manage to migrate all projects to gitlab. But so is the plan to retire Xorg or any X toolkit, i.e. this might never happen

10:31 <jrayhawk> But, regardless, the alternative for noscript users to "incomplete history" is "no history"

10:32 <bentiss> no,m the alternative is to pull the git history over https

10:32 <jrayhawk> That's still perfectly possible via urls at the bottom of the cgit repository listing

10:32 <jrayhawk> which, again, we have to do regardless

10:33 <bentiss> or directly in the generated wiki page?

10:34 <jrayhawk> That's not been a thing so far and seems needlessly cluttery to me, but is certainly possible.

10:34 <bentiss> why adding an url to cgit that then is an url to the repo better than just adding "fork me on github^Wgitlab"?

10:35 <bentiss> and... you already added the "Repo Info" in your change

10:36 <jrayhawk> Cgit provides access to discrete page history without need of additional tooling or bandwidth for the git repository in bandwidth, security, or resource constrained environments.

10:36 <jrayhawk> bentiss: What did I add? I'm confused.

10:37 <bentiss> you still need network for that, no???? so then you should bring your own laptop with a git fork and no need to have network at all

10:37 <bentiss> jrayhawk: I missed that the "Repo Info" link was already there, that's the change you did in the patch from above

10:37 <jrayhawk> That would be optimal, but not all conditions are optimal.

10:38 <bentiss> jrayhawk: that would be a different constraint for you

10:38 <bentiss> but asking admins to maintain a failing system forever because you have a constraint that no one else have is not fair IMO

10:38 <jrayhawk> I am not the only one, I am simply only loud one.

10:40 <bentiss> well, we heared you and gave you already 2 solutions: 1. use the generated page which has not changed in the transition from cgit to gitlab, and 2. use a local git fork (the URL is in the generated page in the "Repo Info" button) to work around the noscripts *when you need access to the history*

10:40 <jrayhawk> If you would like molly to not fail, I am fine with maintaining that.

10:41 <bentiss> re molly -> not my decision

10:41 <jrayhawk> I was previously maintaining cgit just fine on annarchy until other admins complained about having multiple copies of it.

10:42 <bentiss> that is something to talk to the board and the other admins I guess. But AFAICT, the problem is that we have no plans

10:47 <bentiss> anyway, I think that's all I wanted to say. I am not involved in cgit, but I would rather not have another dependency on it from the gitlab side.

11:02 <jrayhawk> What's the normal way to share resources between repositories in build environments, such as fdo.pm and page.tmpl? Is that just git submodules?

11:29 <jrayhawk> oh, no, i do have access to molly at this point. my mistake.

11:32 <jrayhawk> I'm not actually familiar with the architectural plans at this point; is kemper remaining canonical for repositories, or is that all moving to gitlab?

11:33 <jrayhawk> Is there somewhere I should read up on all this?

12:09 <daniels> everything but the kernel moved to GitLab a long time ago

12:11 <daniels> https://lists.freedesktop.org/archives/freedesktop/2018-July/000370.html

12:19 <jrayhawk> And the wikis, and personal repositories

12:25 <jrayhawk> How does synchronization currently work? Is that gitlab pushing over ssh? What breaks on that?

12:31 <jrayhawk> Ah, yes, ssh.

12:32 <daniels> we didn't move personal repos en masse, but realistically most people moved their own

14:11 <karolherbst> jrayhawk: you can also just pull the CI artifacts, then you have the html files locally

14:13 <karolherbst> jrayhawk: you can also use https to push

14:13 <karolherbst> though I suspect the sync still happen over ssh :/

14:14 <karolherbst> anyway.. if you have no internet access then you are screwed anyway, for anything else there is https (which would be stupid to block, so I suspect nobody is doing that, and if so, then run :) )

17:29 <karolherbst> another alternative is to git pull via https and run the ikiwiki generation themselves

17:29 <karolherbst> it's all in the repo anyway

17:29 <karolherbst> and the old infra doesn't even allow that, because of server side secretly hidden files, so even that gets improved