2:09 p.m.
As indicated 10 days ago, today was time for a release, I didn't
had much time so I simply generated a release from libvirt git
without much testing. Hopefully this will be okay !
Release is available as usual at
ftp://libvirt.org/libvirt/
There is actually a number of significant features rolled in this
release, along with the usual fixes and improvements:
Features:
- new API virDomainIsUpdated (Osier Yang)
- Add support for iSCSI target auto-discovery (Daniel P. Berrange)
- QED: Basic support for QED images (Adam Litke)
- Introduce a virDomainOpenConsole API (Daniel P. Berrange)
- Support for SPICE graphics (Daniel P. Berrange)
- Add a sysinfo and SMBIOS support (Daniel Veillard)
- Implement virsh qemu-monitor-command. (Chris Lalancette)
Documentation:
- updated c# bindings with arnauds latest changes (Justin Clift)
- Fix spelling of virBufferVSprintf (Jiri Denemark)
- Fix broken XML entity for '>' (Philipp Hahn)
- removed outdated reference to virt-mem (Justin Clift)
- Add doc for missed options of migrate (Osier Yang)
- add doc for missed parameters of attach-disk (Osier Yang)
- update virsh manual (Osier Yang)
- updated virsh command reference with libvirt.org links (Justin Clift)
- Generate HACKING from docs/hacking.html.in (Matthias Bolte)
- Prepare hacking.html.in to generate HACKING from it (Matthias Bolte)
- updated csharp pages with latest info (Justin Clift)
- trivial typo fix (Justin Clift)
- added virsh command reference page. (Justin Clift)
- rpm: Fix summary wording (Cole Robinson)
- Augment bug reporting documentation (Daniel Veillard)
- virsh: fix incorrect help text mentioning non-existent network 'id' (Justin
Clift)
- Fix off-by-1 in todo page generator (Daniel P. Berrange)
- Fix comment for <video> tag in domain RNG schema (Daniel P. Berrange)
- fix typo (Eric Blake)
Portability:
- remote: Fix TLS transport on Windows (Matthias Bolte)
- Rename 'remove' param to 'toremove' to avoid clash with stdio.h (Daniel
P. Berrange)
- virt-aa-helper: Fix several compile errors (Matthias Bolte)
- maint: improve i18n on non-Linux (Eric Blake)
- nwfilter: use /bin/sh rather than requiring bash (Eric Blake)
- Use python discovered through env instead of hardcoding a path (Matthias Bolte)
- esx: Avoid warnings about breaking strict-aliasing rules on FreeBSD (Matthias Bolte)
- Make sure struct sockaddr_in is defined on FreeBSD (Matthias Bolte)
- configure: Disable FS storage driver if mntent.h is not available (Matthias Bolte)
- daemon: Include stdlib.h in dispatch.c (Matthias Bolte)
- xen: work with xen 4.0.1 headers (Eric Blake)
- Fix build with polkit 0 (Jim Fehlig)
- xen: work with ia64 MAX_VIRT_CPUS of 64 (Eric Blake)
- build: cleanup declaration of xen tests. (Diego Elio Pettenò)
- qemu: check compression program availability of virsh save and dump (KAMEZAWA Hiroyuki)
Bug Fixes:
- correct the arguments of migrate_speed (Wen Congyang)
- Fix memory leaks in audit & VirtualBox code (Daniel P. Berrange)
- Fix host CPU counting on unusual NUMA topologies (Jiri Denemark)
- security, storage: plug memory leaks for security_context_t (Eric Blake)
- network: plug memory leak (Eric Blake)
- qemu: plug memory leak (Eric Blake)
- Always close drivers when a virConnectPtr is released (Matthias Bolte)
- libvirtd: fix bug when shrinking number of clients (Eric Blake)
- Fix 32-bit int truncation in QED header check (Daniel P. Berrange)
- Fix error handling in virsh when listing storage volumes (Daniel P. Berrange)
- Fix parsing of port attribute in storage XML configuration (Daniel P. Berrange)
- Don't catch SIGCHLD in libvirtd (Daniel P. Berrange)
- Ensure logfile isn't truncated by shutdown message. (Daniel P. Berrange)
- xend: Escape reserved sexpr characters (Cole Robinson)
- xend: urlencode: Properly escape '&' (Cole Robinson)
- conf: Fix parsing python style triple quotes (Cole Robinson)
- nwfilter: re-order lock grabbed by IP addr. learn thread (Stefan Berger)
- virExec: fix bug in setting up child stderr/out with /dev/null (Daniel P. Berrange)
- Fix a failure to restore SELinux label for character devices (Daniel Veillard)
- nwfilter: also purge ip(6)tables rules before detecting IP address (Stefan Berger)
- Fix ipv4-addr definition in interface.rng (Laine Stump)
- remote_driver.c: fix non-literal format strings w/o args (Laine Stump)
- ignore SELinuxSetFilecon error in SELinuxSetSecurityFileLabel if on nfs (Laine Stump)
- Fix reference counting bug in virsh console (Daniel P. Berrange)
- Fix busy-wait loop on closed file descriptor (Daniel P. Berrange)
- Fix LXC container console device setup (Daniel P. Berrange)
- rpm: fix /var/lib/libvirt permissions (Eric Blake)
- xencapstest: Don't fail when Xen is installed (Matthias Bolte)
- virsh: fix non-literal string format (Laine Stump)
- Fix syntax-check error in domain.rng (Matthias Bolte)
- qemu: Fix non-literal format string (Jiri Denemark)
- macvtap: libvirtd forgot macvtap dev name when restarted (Stefan Berger)
- tests: fix daemon-conf testing failure (Osier Yang)
- Fix virPipeReadUntilEOF on more than 1024 bytes of data (Daniel Veillard)
- Misc error handling fixes in text mode monitor commands (Daniel P. Berrange)
- Ignore open failures when relabelling disk images (Daniel P. Berrange)
- Treat failure to relabel stdin_path as non-fatal on NFS (Daniel P. Berrange)
- qemu: add the USB devices to the cgroup whitelist (Diego Elio Pettenò)
Improvements:
- Log client errors in libvirtd at debug priority
- maint: prohibit most uses of xmlGetProp (Eric Blake)
- maint: ensure syntax check exceptions are distributed (Eric Blake)
- Implementations of virDomainIsUpdated for drivers except qemu (Osier Yang)
- implement callback function for qemu driver (Osier Yang)
- implement the remote protocol (Osier Yang)
- implement public API virDomainIsUpdated (Osier Yang)
- define internal driver API (Osier Yang)
- tests: Fix dispatching internal error reports (Cole Robinson)
- Improve SCSI volume name generation (Daniel P. Berrange)
- Fix error codes returned when a storage pool is inactive (Daniel P. Berrange)
- Check whether pools are already active upon libvirtd startup (Daniel P. Berrange)
- Allow iSCSI IQN to be set with find-storage-pool-sources-as command (Daniel P.
Berrange)
- Switch the virsh XML generation to use virBuffer instead of virAsprintf (Daniel P.
Berrange)
- Stop iSCSI targets automatically logging back in after logout (Daniel P. Berrange)
- Refactor iSCSI driver code to facilitate future changes (Daniel P. Berrange)
- Ensure virExec preserves logging environment (Daniel P. Berrange)
- Include a thread identifier in log messages (Daniel P. Berrange)
- qemu: setvcpus: Save config changes to disk (Cole Robinson)
- qemu: setvcpus: Simplify altering the persistent config (Cole Robinson)
- qemu: setvcpus: Fix maxvcpus check (Cole Robinson)
- conf: domain: Improve vcpus validation reporting (Cole Robinson)
- Make state driver device hotplug/update actually transient (Cole Robinson)
- domain_conf: Add virDomainObjSetDefTransient (Cole Robinson)
- buf: Simplify virBufferEscapeString (Cole Robinson)
- conf: Convert ParseString to use STRPREFIX (Cole Robinson)
- schemas: domain: Add more valid file path chars (Cole Robinson)
- qed: Minor updates to QED support patches (Adam Litke)
- Support for probing qed image metadata (Adam Litke)
- storage_file: Add a new flag to mark backing files that are safe to probe (Adam Litke)
- Allow probing of image formats without version information (Adam Litke)
- maint: tighten strncmp syntax check (Eric Blake)
- capabilities, cpu: use new array API (Eric Blake)
- memory: make it easier to avoid quadratic scaling of arrays (Eric Blake)
- memory: make it safer to expand arrays (Eric Blake)
- build: fix autobuild failures on gcov upgrade (Eric Blake)
- virt-aa-helper: translate error messages (Eric Blake)
- maint: update to latest gnulib (Eric Blake)
- deprecate fclose() and introduce VIR_{FORCE_}FCLOSE() (Stefan Berger)
- qemu: record timestamp in qemu domain log (Osier Yang)
- virsh: add net-info command (Osier Yang)
- interface.rng: Make miimon and arpmon optional for bond interfaces (Laine Stump)
- macvtap: convert send / recv function to use libnl (Stefan Berger)
- configure: Remove bashism and replace 'test ==' with 'test =' (Matthias
Bolte)
- virsh: Fix compile error in VPATH build (Matthias Bolte)
- qemu: Remove unnecessary quoting from the process name argument (John Morrissey)
- phyp: Don't do a flags check in the storage driver (Matthias Bolte)
- qemu: Add qemu-system-s390x to the emulators list (Matthias Bolte)
- macvtap: convert nl msg construction to use libnl (Stefan Berger)
- Do a better job of validating IP and MAC addresses in network.rng (Laine Stump)
- virt-aa-helper should require <uuid> in XML (Jamie Strandboge)
- esx: Support SMBIOS host mode (Matthias Bolte)
- Wire up virDomainOpenConsole for LXC, Xen and UML (Daniel P. Berrange)
- Re-write virsh console to use streams (Daniel P. Berrange)
- Convert daemon/events.c to use virMutex and virThread (Daniel P. Berrange)
- Introduce portability APIs for creating threads (Daniel P. Berrange)
- Support virDomainOpenConsole with QEMU (Daniel P. Berrange)
- Add a generic internal API for handling any FD based stream (Daniel P. Berrange)
- Lower logging level in remote driver streams (Daniel P. Berrange)
- Remote driver client and server for virDomainOpenConsole (Daniel P. Berrange)
- Support callbacks on virStream APIs in remote driver client (Daniel P. Berrange)
- virsh: supply long option for -V (Eric Blake)
- qemu: Add flag to force a CDROM eject (Cole Robinson)
- Allow non-file disk backingStores (Adam Litke)
- bye to close(), welcome to VIR_(FORCE_)CLOSE() (Stefan Berger)
- esx: Add support for memtune/min_guarantee (Matthias Bolte)
- schema: Move timer element inside clock (Jiri Denemark)
- Misc test case fixes for SPICE (Daniel P. Berrange)
- virsh: Add .xml suffix to tmp files used in *edit commands (Jiri Denemark)
- Support SPICE channel security options (Daniel P. Berrange)
- Support multiple QXL video cards (Daniel P. Berrange)
- Define XML syntax for password expiry (Daniel P. Berrange)
- Add SPICE support for QEMU driver configuration file (Daniel P. Berrange)
- Support automatic port number allocation for SPICE (Daniel P. Berrange)
- Implement QEMU/KVM QXL video card support in QEMU driver (Daniel P. Berrange)
- Add a <graphics> type for SPICE protocol (Daniel P. Berrange)
- Add a QXL graphics card type to domain XML schema (Daniel P. Berrange)
- Show compiled in options in virsh -V (Daniel Veillard)
- lxc: Exit on first error in lxcDomainGetMemoryParameters (Matthias Bolte)
- Allow virDomainGetMemoryParameters on read-only connections (Matthias Bolte)
- Add a new test for sysinfo and smbios handling (Daniel Veillard)
- Add sysinfo/smbios support to the QEmu driver (Daniel Veillard)
- Read the host sysinfo for the QEmu driver (Daniel Veillard)
- Add smbios element to schema and configuration to HVM os (Daniel Veillard)
- Sysinfo parsing and saving to/from configuration files (Daniel Veillard)
- Sysinfo extension to relax-ng schemas (Daniel Veillard)
- Change calling conventions in remote driver client internals (Daniel P. Berrange)
- util: Add helper function to build timestamp string (Osier Yang)
- misc: encode the Emacs suggstions from HACKING into a .dir-locals.el file (Diego Elio
Pettenò)
- add compression support for "virsh dump" (KAMEZAWA Hiroyuki)
- qemu_driver: add virCgroupMounted (Lai Jiangshan)
Cleanups:
- tests: Fix detection of expected errors (Jiri Denemark)
- Remove bogus check for Xen in example program (Daniel P. Berrange)
- build: enforce files.h usage (Eric Blake)
- maint: sort exports (Eric Blake)
- Remove bogus port handling code in virsh (Daniel P. Berrange)
- Remove trailing ':' from timestamp (Daniel P. Berrange)
- Log all errors at level INFO to stop polluting syslog (Daniel P. Berrange)
- daemon: use safer memory growth macros (Eric Blake)
- maint: avoid remaining sprintf uses (Eric Blake)
- maint: use gnulib configmake rather than open-coding things (Eric Blake)
- replace last instances of close() (Stefan Berger)
- daemon: fix indention problem in daemon/libvirt.c (Osier Yang)
- qemu: fix typos in qemu_monitor_text.c (Osier Yang)
- re-indent network.rng following structural change (Laine Stump)
- Put network.rng contents inside <grammar> for uniformity with other RNGs (Laine
Stump)
- maint: Commit .gitignore sorting done by bootstrap (Jiri Denemark)
- xen-proxy: Remove it entirely and use libvirtd instead (Matthias Bolte)
- qemu: Remove redundant slash in save directory path (Matthias Bolte)
- virterror: supply missing spaces (Eric Blake)
- Fix several warnings about a non-literal format string (Jiri Denemark)
- build: avoid compiler warning in xen code (Eric Blake)
Thanks everybody for their input, ideas, patches or documentation
used in this release !
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
9:26 a.m.
Il giorno mar, 30/11/2010 alle 21.09 +0100, Daniel Veillard ha scritto:
As indicated 10 days ago, today was time for a release, I didn't
had much time so I simply generated a release from libvirt git
without much testing. Hopefully this will be okay !
Doesn't seem to be the case :/
In file included from qemu/qemu_conf.c:42:0:
qemu/qemu_conf.h:243:47: warning: 'enum virVMOperationType' declared
inside parameter list
qemu/qemu_conf.h:323:32: warning: 'enum virVMOperationType' declared
inside parameter list
qemu/qemu_conf.c:1646:28: warning: 'enum virVMOperationType' declared
inside parameter list
qemu/qemu_conf.c:1646:47: error: parameter 6 ('vmop') has incomplete
type
qemu/qemu_conf.c: In function 'qemudPhysIfaceConnect':
qemu/qemu_conf.c:1646:47: warning: unused parameter
'vmop' [-Wunused-parameter]
qemu/qemu_conf.c: At top level:
qemu/qemu_conf.c:3959:32: warning: 'enum virVMOperationType' declared
inside parameter list
qemu/qemu_conf.c:3959:51: error: parameter 13 ('vmop') has incomplete
type
qemu/qemu_conf.c: In function 'qemudBuildCommandLine':
qemu/qemu_conf.c:4803:51: error: type of formal parameter 6 is
incomplete
qemu/qemu_conf.c:3959:51: warning: unused parameter
'vmop' [-Wunused-parameter]
make[3]: *** [libvirt_driver_qemu_la-qemu_conf.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
I'll see if I can track this down later… I guess it might be related to
Jean-Baptiste post “Fix warning when macvtap support is disabled”,
especially since I see macvtap references when macvtap is disabled at
configure time.
--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/
If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/
9:47 a.m.
On 02/12/2010, at 2:26 AM, Diego Elio Pettenò wrote:
Il giorno mar, 30/11/2010 alle 21.09 +0100, Daniel Veillard ha
scritto:
>
> As indicated 10 days ago, today was time for a release, I didn't
> had much time so I simply generated a release from libvirt git
> without much testing. Hopefully this will be okay !
Doesn't seem to be the case :/
Ouch, that's two releases in a row with problems showing up straight away after
release.
Looks like it might be time to put some kind of regression testing in place, as a go/no-go
release criteria.
Our adhoc approach isn't working well enough any more.
12:26 p.m.
Il giorno gio, 02/12/2010 alle 02.47 +1100, Justin Clift ha scritto:
Looks like it might be time to put some kind of regression testing in
place, as a go/no-go release criteria.
May I suggest a 1-week (or less) window without merge of new
features/improvements, announced on a separate (low-traffic) mailinglist
for packagers to test the release?
We'd then have time to test whether the code is fine for all of us or
not.
[Speaking as the Gentoo maintainer of libvirt]
--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/
If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/
12:47 p.m.
On 02/12/2010, at 5:26 AM, Diego Elio Pettenò wrote:
Il giorno gio, 02/12/2010 alle 02.47 +1100, Justin Clift ha scritto:
>
> Looks like it might be time to put some kind of regression testing in
> place, as a go/no-go release criteria.
May I suggest a 1-week (or less) window without merge of new
features/improvements, announced on a separate (low-traffic) mailinglist
for packagers to test the release?
We'd then have time to test whether the code is fine for all of us or
not.
Concept wise, do you reckon something like this would work:
+ a new libvirt-announce mailing list, low trafic, purely for release
announcements and similar
Along with us announcing a '"release candidate" build through it (instead of
the
present approach). If it looks good after a period of time (a week or something
as you mentioned), then it gets re-released as the actual release.
If something turns up significantly broken, then we respin as a release candidate
2 and repeat the process.
?
3:01 p.m.
Il giorno gio, 02/12/2010 alle 05.47 +1100, Justin Clift ha scritto:
Concept wise, do you reckon something like this would work:
Yes that looks perfect to me.
--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/
If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/
4:58 a.m.
On Thu, Dec 02, 2010 at 05:47:01AM +1100, Justin Clift wrote:
On 02/12/2010, at 5:26 AM, Diego Elio Pettenò wrote:
> Il giorno gio, 02/12/2010 alle 02.47 +1100, Justin Clift ha scritto:
>>
>> Looks like it might be time to put some kind of regression testing in
>> place, as a go/no-go release criteria.
>
> May I suggest a 1-week (or less) window without merge of new
> features/improvements, announced on a separate (low-traffic) mailinglist
> for packagers to test the release?
>
> We'd then have time to test whether the code is fine for all of us or
> not.
Concept wise, do you reckon something like this would work:
+ a new libvirt-announce mailing list, low trafic, purely for release
announcements and similar
Along with us announcing a '"release candidate" build through it (instead
of the
present approach). If it looks good after a period of time (a week or something
as you mentioned), then it gets re-released as the actual release.
If something turns up significantly broken, then we respin as a release candidate
2 and repeat the process.
I think this is really viable, because it implies we need another
week prior to creating the pre-release where we do what we currently
do with pre-release stabalization. With a monthly release cycle,
taking 2 weeks todo a release is too much of an time sink.
IMHO, we need to have
- A official list of supported platforms / OS combinations
- Run a test build on each combination before release
- Actually follow the 'bug fixes' only rule leading upto release
no matter how simple the new feature might appear.
Daniel
5:07 a.m.
On 02/12/2010, at 9:58 PM, Daniel P. Berrange wrote:
<snip>
I think this is really viable, because it implies we need another
Err... "not" really viable yeah?
week prior to creating the pre-release where we do what we currently
do with pre-release stabalization. With a monthly release cycle,
taking 2 weeks todo a release is too much of an time sink.
IMHO, we need to have
- A official list of supported platforms / OS combinations
Yep, good idea. We should definitely have a list of "core things we support",
plus some way of communicating things also being worked up.
- Run a test build on each combination before release
Yep.
- Actually follow the 'bug fixes' only rule leading upto
release
no matter how simple the new feature might appear.
Would it make sense to branch git at the point we enter "feature freeze",
having the new branch be just for the release in question, and allow people
to continue committing to master? (I'd also think this is the point we could
generate a "release candidate" tarball for people to test if they want)
When bugs turn up in the freeze period, the fixes can be applied to the release
branch. It sounds like it _might_ also mean a bit more work, as the same fixes
will need to be applied to the master branch too.
Good/bad approach?
8:03 a.m.
Il giorno gio, 02/12/2010 alle 10.58 +0000, Daniel P. Berrange ha
scritto:
I think this is really viable, because it implies we need another
week prior to creating the pre-release where we do what we currently
do with pre-release stabalization.
Note that I said “one week or less”.
- A official list of supported platforms / OS combinations
- Run a test build on each combination before release
- Actually follow the 'bug fixes' only rule leading upto release
no matter how simple the new feature might appear.
And let me guess that the "supported platforms" are going to be mostly
RedHat&co.? Why not warning the rest of the packagers, so that each run
their tests?
--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/
If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/
11:27 a.m.
On 03/12/2010, at 1:03 AM, Diego Elio Pettenò wrote:
> - A official list of supported platforms / OS combinations
> - Run a test build on each combination before release
> - Actually follow the 'bug fixes' only rule leading upto release
> no matter how simple the new feature might appear.
And let me guess that the "supported platforms" are going to be mostly
RedHat&co.?
Heh, where did that come from? I kind of hoped you'd noticed we're (Red
Hat) putting effort into widening things from being just Red Hat centric.
*Very* much interested in widening out our officially supported distro's
and platforms.
Why not warning the rest of the packagers, so that each run
their tests?
I actually kind of thinks it's more that our Communication and self
discipline hasn't been as good as needed, looking at the result of
the last two releases. So, this is our opportunity to identify and fix.
With Gentoo, which are the pieces that you reckon are stable enough
that we can document them as being "known good", and rely on them
tested for each new release? Thinking it can't hurt to start getting that
info worked out and put on the site properly.
?
Regards and best wishes,
Justin Clift
12:22 a.m.
On 12/02/2010 03:03 PM, Diego Elio Pettenò wrote:
Il giorno gio, 02/12/2010 alle 10.58 +0000, Daniel P. Berrange ha
scritto:
> I think this is really viable, because it implies we need another
> week prior to creating the pre-release where we do what we currently
> do with pre-release stabalization.
Note that I said “one week or less”.
Less? I'm not sure if everybody can react that fast. I mean there is
more to life than just: uh, new libvirt is out. I have to drop
everything and test it; j/k :)
> - A official list of supported platforms / OS combinations
> - Run a test build on each combination before release
> - Actually follow the 'bug fixes' only rule leading upto release
> no matter how simple the new feature might appear.
And let me guess that the "supported platforms" are going to be mostly
RedHat&co.? Why not warning the rest of the packagers, so that each run
their tests?
This seems to be perfectly fine. You, ehm guys, can't possibly to test
every flavor of GNU/Linux. So it seems to be pretty much okay to me.
It's up to community around each GNU/Linux distribution to do their own
testing.
Just my $0.02USD
Zdenek
--
Zdenek Styblik
Net/Linux admin
OS TurnovFree.net
email: stybla(a)turnovfree.net
jabber: stybla(a)jabber.turnovfree.net
4:28 a.m.
On Thu, Dec 02, 2010 at 03:03:56PM +0100, Diego Elio Pettenò wrote:
Il giorno gio, 02/12/2010 alle 10.58 +0000, Daniel P. Berrange ha
scritto:
> I think this is really viable, because it implies we need another
> week prior to creating the pre-release where we do what we currently
> do with pre-release stabalization.
Note that I said “one week or less”.
> - A official list of supported platforms / OS combinations
> - Run a test build on each combination before release
> - Actually follow the 'bug fixes' only rule leading upto release
> no matter how simple the new feature might appear.
And let me guess that the "supported platforms" are going to be mostly
RedHat&co.? Why not warning the rest of the packagers, so that each run
their tests?
The supported platforms would be whatever we can guarentee are
build tested by someone before release, no intention of artificially
restricting it just to Fedora/RHEL platforms.
Daniel
11:04 p.m.
Daniel P. Berrange wrote:
>
> Concept wise, do you reckon something like this would work:
>
> + a new libvirt-announce mailing list, low trafic, purely for release
> announcements and similar
>
> Along with us announcing a '"release candidate" build through it
(instead of the
> present approach). If it looks good after a period of time (a week or something
> as you mentioned), then it gets re-released as the actual release.
>
> If something turns up significantly broken, then we respin as a release candidate
> 2 and repeat the process.
>
I think this is really viable, because it implies we need another
week prior to creating the pre-release where we do what we currently
do with pre-release stabalization. With a monthly release cycle,
taking 2 weeks todo a release is too much of an time sink.
Perhaps a 24 hour release candidate period? I have a staging project in
openSUSE Build Service that builds for all currently supported SuSE
products, which is a wide range of capabilities wrt Policy Kit versions,
hal vs udev, libnl, avahi versions, cap-ng, netcf, macvtap, virtualport,
yajl, ...
I can deploy a release candidate tarball to the libvirt package in this
project quickly to test building across these various SuSE products. I
suspect there is an opportunity for some automation here as well.
Regards,
Jim
11:37 p.m.
On 03/12/2010, at 4:04 PM, Jim Fehlig wrote:
I can deploy a release candidate tarball to the libvirt package in
this
project quickly to test building across these various SuSE products. I
suspect there is an opportunity for some automation here as well.
Whichever way we go, I think automation within a release or two, if
not right away, would have to be near mandatory. Whatever the delay
period is, there will be times someone discovers a bug/blocker/etc,
and once fixed a new package needs to be created with everyone
testing it again. If the testing itself takes ages, that would be non-optimal.
4:51 a.m.
On Thu, Dec 02, 2010 at 02:47:22AM +1100, Justin Clift wrote:
On 02/12/2010, at 2:26 AM, Diego Elio Pettenò wrote:
> Il giorno mar, 30/11/2010 alle 21.09 +0100, Daniel Veillard ha scritto:
>>
>> As indicated 10 days ago, today was time for a release, I didn't
>> had much time so I simply generated a release from libvirt git
>> without much testing. Hopefully this will be okay !
>
> Doesn't seem to be the case :/
Ouch, that's two releases in a row with problems showing
up straight away after release.
Looks like it might be time to put some kind of regression
testing in place, as a go/no-go release criteria.
Our adhoc approach isn't working well enough any more.
If we had followed our existing rules more strictly it
would be have been fine. The stuff that caused the breakage
was a new feature, so it should not have been merged at
that late stage. All new features should have been merged
a week before, with only bug fixes following.
Daniel
10:28 a.m.
2010/12/1 Diego Elio Pettenò <flameeyes(a)gmail.com>:
Il giorno mar, 30/11/2010 alle 21.09 +0100, Daniel Veillard ha
scritto:
>
> As indicated 10 days ago, today was time for a release, I didn't
> had much time so I simply generated a release from libvirt git
> without much testing. Hopefully this will be okay !
Doesn't seem to be the case :/
In file included from qemu/qemu_conf.c:42:0:
qemu/qemu_conf.h:243:47: warning: 'enum virVMOperationType' declared
inside parameter list
qemu/qemu_conf.h:323:32: warning: 'enum virVMOperationType' declared
inside parameter list
qemu/qemu_conf.c:1646:28: warning: 'enum virVMOperationType' declared
inside parameter list
qemu/qemu_conf.c:1646:47: error: parameter 6 ('vmop') has incomplete
type
qemu/qemu_conf.c: In function 'qemudPhysIfaceConnect':
qemu/qemu_conf.c:1646:47: warning: unused parameter
'vmop' [-Wunused-parameter]
qemu/qemu_conf.c: At top level:
qemu/qemu_conf.c:3959:32: warning: 'enum virVMOperationType' declared
inside parameter list
qemu/qemu_conf.c:3959:51: error: parameter 13 ('vmop') has incomplete
type
qemu/qemu_conf.c: In function 'qemudBuildCommandLine':
qemu/qemu_conf.c:4803:51: error: type of formal parameter 6 is
incomplete
qemu/qemu_conf.c:3959:51: warning: unused parameter
'vmop' [-Wunused-parameter]
make[3]: *** [libvirt_driver_qemu_la-qemu_conf.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
I'll see if I can track this down later… I guess it might be related to
Jean-Baptiste post “Fix warning when macvtap support is disabled”,
especially since I see macvtap references when macvtap is disabled at
configure time.
This two commits in git:
Fix undefined symbol errors when macvtap support is disabled
474b1c1487828a17fe9e1025901334d9820ea350
Fix warning when macvtap support is disabled
45147ca37f3d93ea67b02a6c0e435bdf40b4ddc5
should fix the errors you listed above.
Matthias
5100
days inactive
5106
days old
15 comments
7 participants
participants (7)
-
Daniel P. Berrange -
Daniel Veillard -
Diego Elio Pettenò -
Jim Fehlig -
Justin Clift -
Matthias Bolte -
Zdenek Styblik