Thanks again for everyone who's keeping up with the alpha! Let's go over what's been going on lately. general news Lately I've been trying to make sure the infrastructure sr.ht runs on is ready for a long-term sr.ht deployment post-alpha. There's still a lot of software running on the legacy infrastructure, but some of the builds.sr.ht work I'll talk about shortly has been paving the way for migrating everything. I also spent some time adding monitoring to the new infrastructure, with Prometheus and Grafana (both open source). The alarms I configured should let me detect problems before they arise, keeping everything healthy. I'll shortly be instrumenting much of sr.ht's application software as well, making this available to people who run third-party instances so you can keep an eye on your service health, too. Also, everything has been updated to Python 3.7. lists.sr.ht I've got some pretty cool news on this one. Working slowly towards building the integrated code review tooling for lists.sr.ht, I added syntax highlighting for patches sent to sr.ht mailing lists. "Syntax highlighting" doesn't do it justice, though - it also sprinkles links throughout so you can link to specific line numbers and jump to specific files. Here's an example patch I submitted to a friend's project: https://lists.sr.ht/~emersion/public-inbox/%3C20180805132231.7035-1-sir%40cmpwn.com%3E Working on the code review facilities of lists.sr.ht remains a high priority for me, and you can expect to see more work here soon. There have been other minor improvements, the most visible of them being that we also no longer forward emails to you that you were already copied on, on the assumption that the sender's MTA took care of it. builds.sr.ht The FreeBSD and Alpine images I mentioned preparing in the last update revealed some limitations in previous iterations of the builds.sr.ht job runner, so I spent a lot of time improving this in the past week or so. Rather than passing -kernel and -initrd to qemu directly and using a FreeBSD-specific shim to bypass this, I've been working on partitioning images and installing a bootloader on all images. This will make additional BSDs and other, more exotic operating systems more feasible to run builds against. As I finalized this design I also wrote up docs for anyone interested in the process: https://man.sr.ht/builds.sr.ht/installation.md#install-images This doc will also eventually be useful when I add support for custom user-provided build images. I also worked on making all of the build images self-hosting, something I started a while ago but never put a bow on. This means that, for example, the Debian build images can be built during a Debian builds.sr.ht job. Now that this is mostly in place, all of the images* are building themselves every night, keeping the images fresh and making sure builds aren't slowed down waiting for system updates to run every time. * Except FreeBSD. I got this partially done, but ran into some issues. BSD wizards, please email me if you can help. Coming soon: Fedora, CentOS, and Ubuntu images. Maybe Gentoo? Would also appreciate an email from a Gentoo user who wants to volunteer some expertise on how best to support it. I have some more polish to add to builds.sr.ht soon, like resubmitting jobs and submitting multiple manifests on git pushes.
On 15.08.2018 at 03:34, Drew DeVault wrote: > > lists.sr.ht > > I've got some pretty cool news on this one. Working slowly towards > building the integrated code review tooling for lists.sr.ht, I added > syntax highlighting for patches sent to sr.ht mailing lists. "Syntax > highlighting" doesn't do it justice, though - it also sprinkles links > throughout so you can link to specific line numbers and jump to specific > files. Here's an example patch I submitted to a friend's project: > > https://lists.sr.ht/~emersion/public-inbox/%3C20180805132231.7035-1-sir%40cmpwn.com%3E Existing code review tools, such as gerrit or pull requests on github, when displaying a patch, have a button to expand the diff context, i.e. to display more code not touched by the patch around the changes. I guess it'd be hard for lists.sr.ht to implement such a feature now, but the links-to-file-parts-of-diff feature made me come up with another idea: How about having links from the diff to unmodified versions of files on git.sr.ht ? They could be in the +++ part of diff, or even in the @@ part, linking to specific lines in the original file. This would allow a reviewer to quickly see the larger context of the changes by opening the original file in another tab. I think the hardest problem to implement this would be finding a way to tell lists.sr.ht which git repo the patch is for, but such information will probably be needed for other future features anyway. What do you think about this idea? -- Wolf480pl
On 2018-08-21 2:32 PM, Wolf480pl wrote: > Existing code review tools, such as gerrit or pull requests on github, > when displaying a patch, have a button to expand the diff context, > i.e. to display more code not touched by the patch around the changes. This is something I eventually want to support. It's blocked by sorting out all of the details of the APIs used between sr.ht services themsevles and between sr.ht services and the outside world. The feature suggested in the rest of your email will likely be possible, too. It will take some time, though.