On 19/08/2021 18:35, Stefan Reinauer wrote:
On Thu, Aug 19, 2021 at 3:13 AM Philippe Mathieu-Daudé <f4bug@amsat.org mailto:f4bug@amsat.org> wrote:
On Thu, Aug 19, 2021 at 11:02 AM Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk <mailto:mark.cave-ayland@ilande.co.uk>> wrote: > > Hi all, > > Since the coreboot team moved the OpenBIOS project onto Github, there have been a > number of steadily increasing pull requests and issues raised there and so I'm > wondering if now is the time to start thinking about moving to a more Github-based > workflow. Why GitHub and not GitLab?Good question. Because that is where the code already lives, so it is a minimal change for everybody So if you want to suggest that to change, the question might be: Why GitLab and not GitHub?
QEMU have decided on GitLab so there may be a slight preference there, but otherwise I don't believe there is too much difference between both services?
> The nice thing about Github is that we can start to put together some CI to allow > build testing of PRs and open potential review to people outside of the OpenBIOS > mailing list. However there are a number of very knowledgeable people on this mailing > list who have helped with the project over the years and I am really keen to maintain > the benefit of their expertise. I'm pretty sure some 'bots' exist that can send PR patches via email to the list.Yes we can do this I'm pretty sure.
Personally I find the Web-UI review process awkward (besides most of the time I do review I'm offline), and hard to grep (instead of an email archive).Yes, particularly the github work flow is a bit cumbersome, at least if you're not used to it initially. On the positive side, you can always download pull requests to your git tree to test and review locally.
I tend to find that this is based upon experience: for new contributors it is much easier to open a PR on Github and manage the review/merge there, whereas for higher volume patch management (and also people used to kernel workflow) mailing lists tend to work much better in my experience.
Also it makes it harder for blind developers to contribute, but I think git forge projects are trying to catch up there.There is a github command line client that might help with this.
Anyway we all have to adapt, and I agree using git forges help to reach another audience (as long as it doesn't kick out the current one). CI is certainly a big win.Yes, this can really change our quality in the long run.
> On this basis I would like to propose the following changes: > > 1) Move to a merge request workflow and start accepting PRs from Github > > 2) Add the openbios@openbios.org <mailto:openbios@openbios.org> mailing list automatically to Github PRs > and Issues so people on the mailing can take part in the discussions. > Note: this is currently VERY low volume. > > 3) Implement a basic Github workflow using the QEMU project cross-compiler > docker images to enable build testing and artifact generation without > requiring a cross-compiler to be built manually. (I've already tried a few > experiments and made some progress here).This sounds great!
I haven't used Github workflows before but it was a reasonably straightforward experience to get it up and running thanks to the QEMU docker images. See https://github.com/mcayland/openbios/commit/a027ba769f9cd53c75ac96d60b6839f8... for building x86, amd64, sparc32, sparc64 and ppc images and storing the artifacts.
Merging the workflow should cause the build to run when cloned repositories push to branches so we can at least get some basic checks in place for contributors who raise PRs.
> Any further thoughts/ideas/suggestions?If we're making infrastructure changes, do we want to switch from MediaWiki to a different solution for the web page?
MediaWiki is okay, although it is a slightly higher bar to make changes given that wiki accounts need to be set up separately.
(And we should do a release, the last release update on the web page was 8 years ago)
Yeah I guess that's my fault. Blue Swirl used to do the release management and I was never particularly confident to do that with SVN, although git is much easier. Certainly there have been many, many fixes and improvements since the last release.
ATB,
Mark.