On Fri, 09/04 13:41, Daniel P. Berrange wrote: > FYI, earlier this year the CentOS project started a new effort to > provide CI services to open source infrastructure projects. We have > started using them to CI of all libvirt pieces, virt-manager, and > libguestfs. In our initial discussions they also expressed an > interest in supporting QEMU too. > > Essentially they provide a public Jenkins service you can see > here: > > https://ci.centos.org/ > > There's not much written about this except for this sparse page > > https://wiki.centos.org/QaWiki/CI > > IIUC, it is x86 only, but even if it can't do everything QEMU > needs, it might be a useful service to take advantage of for > some parts of QEMU CI.
Good to know! Yes, eventually QEMU might need more than one Jenkins instances to cover different hosts, x86 should be a good start. I'll keep an eye on. Thanks, Fam > > > * Security process > > * We've improved and documented our security process over the last > > year or so, but it could still be improved. > > * Big problem -- we fix CVEs on master, but we don't provide a stable > > release with security fixes until the next time we would have > > done a release anyway; this can mean we go for months without > > any available stable release without known security issues. > > * We could do a stable release immediately we have a CVE, but this > > is obviously more work for our stable maintainer (Michael Roth). > > We might get a few CVEs a cycle, though obviously it varies. > > * Proposal to mitigate this: > > + go to one full stable release per cycle, rather than the > > theoretical two per cycle we currently try for (ie one per > > 4 months, not per 2 months) > > + somebody else to do the backport-patch-to-stable (Stefano > > Stabellini volunteered for this since he has to already for > > anything which affects Xen) > > + the intermediate stable releases for security issues would only > > contain the CVE fixes, not be a full "flush the stable queue" > > release > > + stable maintainer to be looped in pre-disclosure date so > > there is good notice of CVE fixes rather than it being an > > unpleasant surprise > > + sychronize disclosure dates for CVEs that are reported close together > > + categorize reported vulnerabilities into "moderate or important: > > goes through disclosure process and gets stable release" vs > > "minor: no delayed disclosure, no stable release" to avoid > > invoking the machinery for the truly trivial (eg the rash of > > 'vulnerable to malicious incoming migration data' bugs we had > > a while back) > > Even if QEMU doesn't provide a backported patch for stable, it would > be desirable to at least provide a formal report giving information > on /when/ a flaw was introduced to QEMU, so downstream consumers can > identify whether they're likely vulnerable or not. I've mentioned > a few times before that libvirt has a simple XML file format + support > tools that can record & publish this kind of metadata in text, html > and xml format. eg this doc > > http://security.libvirt.org/2015/0002.html > > In this case we did indeed fix all historic branches since it was > a trivial cherry-pick, but sometimes we just mention the broken-by > commit and not any fixed-by, so it is clear whether the old branch > is vulernable or not. The tools are all open source here > > http://libvirt.org/git/?p=libvirt-security-notice.git;a=summary > > > > * Review > > * Patch review workload remains an issue for many submaintainers. > > * Patches not getting reviewed promptly is dispiriting, especially > > for new contributors. > > * One suggestion for this is an approach described by Sarah Sharp > > in this blog post: > > http://sarah.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/ > > The general idea is to split review into three phases, where the > > first phase is just a "is the idea behind this patch good?" with a > > quick yes/no answer, and (if the answer is 'yes') to send a mail saying > > so and that the patch is on your to-review queue. > > From the POV of a contributor I think it would be very attractive to > have such a response confirming whether a proposed patch is conceptually > sane vs crazy. Ultimately contributors can accept that reviewers are > overworked and wait patiently as long as there's indication that their > work is going to be useful to the project. What's depressing is when > you get upto version 10 of a patch series and only then get a response > saying your design is crazy. > > > * Better documentation for new contributors > > * Poor documentation of design/internals can be a barrier to > > new contributors. > > * We have improved here, but we have to improve more. > > * Missing documentation includes how-to style information on tasks > > like 'adding a new device' or 'new target frontend', etc. > > We should encourage the inclusion of more inline API docs in the header > files to help people understand how the internal infrastructure works, > any time a new internal API is added. > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| >
