Ludovic Courtès <l...@gnu.org> writes: > Hello! > > Christopher Baines <m...@cbaines.net> skribis: > >> ... >> >> I've now written a very rough package and service for Patchwork [4], and >> managed to setup a instance here [5]. With the help of an email account >> subscribed to both guix-patches and guix-commits, getmail and a couple >> of scripts, it should also collect new patches sent to guix-patches, and >> mark those that have been merged to the master branch as "Accepted" [6]. >> >> ... > > Back when we tried, it had a couple of shortcomings: > > 1. It would not automatically detect which patches have been merged; > > 2. It would not present patch series correctly. > > From what you write it looks like #1 has been fixed, but the web > interface suggests that #2 isn’t quite fixed yet, is that correct?
On the detecting merged patches, that's definately working for some patches though. I don't fully understand what criteria it's using though, as it's comparing the commits that come through to the master branch, and I bet it's possible to confuse it a bit by tweaking patches before pushing them. Regarding patch series, I don't know much about the specifics of this, and I don't know much about Patchwork, but just comparing a few patches on the older version [1], and the newer version [2], it looks like it's better. Take this patch [3], it's part of a series, but you can't tell. However, with this patch [4], you can see the series and related patches towards the top of the page, and also a link to download the whole series as an mbox. How does this look to you? 1: https://patchwork.sourceware.org/project/guix/list/ 2: https://patchwork.cbaines.net/project/guix-patches/list/ 3: https://patchwork.sourceware.org/patch/18558/ 4: https://patchwork.cbaines.net/patch/66/ >> I don't intend to do anything with Jenkins, as I think that wouldn't be >> maintainable, but I think setting up some system to check some of the >> following would be beneficial: >> >> - If a patch series applies to master >> - If ./configure and make run successfully >> - If building a guix package with the patch applied works >> - If running guix lint for all the new/changed packages works >> - If building all the new/changed packages works >> - If running the tests and system tests works > > I think these are all things we’d love to see. > > Apart from item #1, the rest is pretty much Guix-specific. My > suggestion would be to write tooling piecemeal: for example, things that > allow us to determine the set of packages added or upgraded by a patch > (we actually have a bit of that with ‘guix pull’ and (guix inferior)), > things to apply patches, etc. > > We don’t want to reimplement Patchwork, GitLab, etc. so anything that > can be borrowed from there is welcome. > > What might be nice is integration with Cuirass: if it had an HTTP API to > easily request a branch build, we could easily hook into it; and then, > we can extended its existing HTTP API as we see fit to make it easy to > retrieve info about build statuses and so on. > > All this is easier said than done, but my point is that we should try > and identify easily doable bits so we can incrementally build such a > tool. That all matches up well with what I've been thinking about :)
signature.asc
Description: PGP signature