#131 Improve internal site switching 26 days ago

Comment by ~andrewrk on ~sircmpwn/todo.sr.ht

As an example, right this second I am looking at a ticket for ~sircmpwn/todo.sr.ht. And I want to go look at the mailing lists for todo.sr.ht. As far as I'm aware there is no way to navigate from this page, to that page, without manually editing the URL. Another problem is that if I was unaware that there was a mailing list, there is no way to discover it, from here.

#131 Improve internal site switching 26 days ago

Comment by ~andrewrk on ~sircmpwn/todo.sr.ht

I agree that cross-service linking in its current form is a problem, although I'm not sure I understand your suggested solution.

I think the crux of the matter comes down to this: if someone is used to looking at GitHub or GitLab, for example, there are services all available in the menu laid out in tab form that correspond to sr.ht services. For example, Code, Issues, Pull Requests, Projects, Wiki, Settings. These links are all "project-local" links.

Now, looking at sr.ht, there are corresponding links at the top, laid out in tabs as expected, however these are not "project-local" links - they are global links to sr.ht services. This is confusing for the uninitiated.

Even for the initiated, however, I would argue it is far more common, when looking at any given service for a project, to want to see the other services available for that project, than it is to want to explore more sr.ht services independent from any project. I would expect the prominence of the UI buttons to reflect this.

#134 feature request: preview button when creating/editing tickets 26 days ago

Ticket created by ~andrewrk on ~sircmpwn/todo.sr.ht

It prevents unnecessary edits to have a preview button to test if the markdown is rendered as desired, before submitting/saving edits.

I searched for "preview" before creating this ticket with no results, so I think this may be the first formal request for this feature.

#150 use case: use external hardware as image 26 days ago

Ticket created by ~andrewrk on ~sircmpwn/builds.sr.ht

Here's a use case, and maybe you can tell me whether this is something that is in scope of builds.sr.ht or not, and what is the best way to resolve the use case.

I want to test a lot of different architectures and OSes for Zig. sr.ht covers some of the options with the available images. Great. I also have additional hardware sitting on my desk, e.g. 2 Raspberry Pis (aarch64), one with Linux and one with FreeBSD.

Would it be possible to integrate these with builds.sr.ht? For example, I could install some kind of sr.ht client on the rpis, which allow builds.sr.ht to send builds to them, and report the results back. I could imagine, once it's installed and integrated, from the frontend it would like like image: my_linux_rpi or image: my_freebsd_rpi where these names are specified in the configuration/integration process.

This would also allow users to donate hardware to a project to make it available for running tests on.

Edit: I want to add, the motivation for having all the CI tests in sr.ht instead of having multiple independent CI services, is to make it easier to have a final "update download page" step, which runs only if all other CI steps completed successfully. Here's an example of what that looks like for zig currently:

In Azure DevOps which is what we currently use, the config for this looks like:

- job: UpdateDownloadPage
  - BuildMacOS
  - BuildLinux
  - BuildWindows
condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))