~sircmpwn/sr.ht-announce

2 2

What's cooking on sr.ht

Details
Message ID
<20180815013434.GA9895@homura.localdomain>
Sender timestamp
1534296874
DKIM signature
permerror
Download raw message
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.
Details
Message ID
<2f0bc798-3ae7-dcd9-c5e9-718fbe6d2881@interia.pl>
In-Reply-To
<20180815013434.GA9895@homura.localdomain> (view parent)
Sender timestamp
1534854745
DKIM signature
pass
Download raw message
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
Details
Message ID
<20180821124400.GA1154@homura.localdomain>
In-Reply-To
<2f0bc798-3ae7-dcd9-c5e9-718fbe6d2881@interia.pl> (view parent)
Sender timestamp
1534855440
DKIM signature
permerror
Download raw message
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.