Hopefully last questions: 1) What's the format for the subject line for patches? I'm seeing things like "[PATCH 2/4]" or "[PATCH v2 00/10]" what do those numbers mean in this context? I didn't see anything about this mentioned in the SubmitAPatch wiki. 2) Is it acceptable to have a patch for the configure script, or is that generated? I found some Haiku-related issues there 3) Is there a way to specify that the patch is for a submodule, or is there a separate place for that?
Regarding prior email: Seems like the big tasks are: 1) Haiku VM for continuous integration. Is this hosted in Amazon or other cloud infrastructure? 2) Resolving issues with Haiku pertaining to testing, bringing it inline with other OSes (and I see how the disk space error) 3) Supporting aspects of the qemu code relevant to Haiku (found an issue in slirp & configure script) Thank you for your help & patience! În vin., 25 iun. 2021 la 23:03, Warner Losh <i...@bsdimp.com> a scris: > > > On Fri, Jun 25, 2021 at 8:45 PM Richard Zak <richard.j....@gmail.com> > wrote: > >> Hello and thanks for the detailed response! I wasn't aware that a Linux >> host could compile for Haiku as a target, that's interesting. >> >> Seems like the big tasks are: >> 1) Haiku VM for continuous integration. Is this hosted in Amazon or other >> cloud infrastructure? >> > > Take a look at, for example, the make vm-build-freebsd target (see > tests/vm/Makefile.include). It downloads > the latest FreeBSD images, boots it with a serial console, walks through > the install of the base OS, then > installs the packages needed for qemu to build and kicks off a build and > runs some acceptance tests > afterwards. OpenBSD, NetBSD and several Linux distributions have similar > setups. I think it would be > useful for there to be one for Haiku as well, so any developer could run > these tests either in response to > a bug report in their code, or to make sure things work on/with Haiku. All > of this is done locally. > > There's a separate issue for creating a Haiku runner for gitlab, but I > know little even about the FreeBSD > runner. > > >> 2) Supporting aspects of the qemu code relevant to Haiku. >> >> I'll take a look at that Wiki page to get a feel for things, and I've >> started with the compilation of the latest code from the repo on Haiku, >> addressing some issues as they come up. >> >> I am a huge fan of both projects, but also am doing this in my own time. >> I'm a developer professionally, but working on Haiku & qemu during off >> hours (though timely shouldn't be a problem). How are things communicated >> for this project (in regard to your request for someone who can help in a >> timely manner)? It seems that the vast majority of the mailing list is >> patch information. What's the primary way for code to be contributed, a >> merging code though Gitlab or via emailed >> > patches? >> > > Emailed patches. https://wiki.qemu.org/Contribute/SubmitAPatch has all > the details, though the volume of patches means that you really want to > make sure that you CC the maintainers of the code listed in the MAINTAINERS > file when submitting patches to help ensure they do not get list. > > Warner > > >> >> În vin., 25 iun. 2021 la 03:09, Thomas Huth <th...@redhat.com> a scris: >> >>> On 25/06/2021 06.12, Richard Zak wrote: >>> > Hello there! I noticed the message which appears when building qemu on >>> > Haiku. I'd hate for Haiku to lose qemu, so I would like to help! >>> > >>> > What is needed in terms of a build system for continuous integration? >>> I'm >>> > not familiar with CI systems, other than simply knowing what they do. >>> >>> Hi, >>> >>> since a couple of month, we already have a Haiku VM in our VM tests, so >>> the >>> basics are already there - it's possible to run a Haiku build test on a >>> Linux host by typing: >>> >>> make vm-build-haiku.x86_64 >>> >>> However, it's still in a quite bad shape, the disk image that is used in >>> that VM is not big enough for compiling the whole QEMU sources. So >>> somebody >>> needs to add some additional logic there to either increase the disk >>> image >>> on the fly or to add a second free disk image to the VM that could be >>> used >>> for compilation instead. If you want to have a try, have a look at: >>> tests/vm/haiku.x86_64 >>> >>> Also, I'm not sure whether Peter is using this VM already in his gating >>> CI >>> tests? I guess not, due to those size limitations... >>> >>> Finally, we'd also need somebody who's proficient with the Haiku APIs >>> and >>> who could help with problems in a timely manner, i.e. we'd need an entry >>> in >>> the "Hosts" section in the maintainers file. It should be someone who's >>> basically familiar with the QEMU development process, so if you're >>> interested, I'd suggest that you try to contribute some patches to QEMU >>> first to get a basic understanding of the process (see e.g. >>> https://wiki.qemu.org/Contribute/BiteSizedTasks for some easier tasks), >>> and >>> once you feel confident, you could add a Haiku entry to the MAINTAINERS >>> file. >>> >>> Thomas >>> >>> >> >> -- >> Regards, >> >> Richard J. Zak >> Professional Genius >> PGP Key: https://keybase.io/rjzak/key.asc >> > -- Regards, Richard J. Zak Professional Genius PGP Key: https://keybase.io/rjzak/key.asc
