| Title: About pipelining OpenBSD ports contributions | |
| Author: Solène | |
| Date: 27 September 2020 | |
| Tags: openbsd automation | |
| Description: | |
| After modest contributions to the NixOS operating system which made | |
| me learn about the contribution process, I found enjoyable to have | |
| an automatic report and feedback about the quality of the submitted | |
| work. While on NixOS this requires GitHub, I think this could be | |
| applied as well on OpenBSD and the mailing list contributing system. | |
| I made a prototype before starting the real work and actually I'm | |
| happy with the result. | |
| This is what I get after feeding the script with a mail containing | |
| a patch: | |
| Determining package path ✓ | |
| Verifying patch isn't committed ✓ | |
| Applying the patch ✓ | |
| Fetching distfiles ✓ | |
| Distfile checksum ✓ | |
| Applying ports patches ✓ | |
| Extracting sources ✓ | |
| Building result ✓ | |
| It requires a lot of checks to find a patch in the file, because | |
| we have have patches generated from cvs or git which have a slightly | |
| different output. And then, we need to find from where to apply | |
| this patch. | |
| The idea would be to retrieve mails sent to [email protected] by | |
| subscribing, then store metadata about that submission into a | |
| database: | |
| Sender | |
| Date | |
| Diff (raw text) | |
| Status (already committed, doesn't apply, apply, compile) | |
| Then, another program will pick a diff from the database, prepare a VM | |
| using a | |
| derivated qcow2 disk from a base image so it always start fresh and | |
| clean and ready, and do the checks within the VM. | |
| Once it is finished, a mail could be sent as a reply to the original | |
| mail to give the status of each step until error or last check. The | |
| database could be reused to make a web page to track what compiles | |
| but is not yet committed. As it's possible to verify if a patch is | |
| committed in the tree, this can automatically prune committed patches | |
| over time. | |
| I really think this can improve tracking patches sent to ports@ and | |
| ease the contribution process. | |
| **DISCLAIMER** | |
| - This would not be an official part of the project, I do it on my own | |
| - This may be cancelled | |
| - This may be a bad idea | |
| - This could be used "as a service" instead of pulling automatically | |
| from ports, meaning people could send mails to it to receive an | |
| automatic review. Ideally this should be done in portcheck(1) but | |
| I'm not sure how to verify a diff apply on the ports tree without | |
| enforcing requirements | |
| - **Human work will still be required to check the content and verify | |
| the port works correctly!** |