Plan for libguestfs 1.34
Libguestfs 1.32 was released on 2016-01-06, which is over 6 months ago. In fact the previous stable version of libguestfs (1.30) was released on 2015-07-21, almost exactly 12 months ago. Are we heading for a 6 month release cycle? Not officially. Anyway, I would like you to think about what needs work for the next stable 1.34 release. Any new APIs added in the 1.33 cycle will become supported and guaranteed when we release 1.34, so we need to check those. See: git diff 1.32.0 -- generator/actions.ml Please follow-up also if there are features / blockers / bugs that need to be addressed for 1.34. As usual, bugs which have "1.34" (without quotes) in the "Devel Whiteboard" field in Bugzilla are nominated as blockers for the release. You can see a list of those here (currently empty): https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=FAILS_QA&bug_status=RELEASE_PENDING&bug_status=POST&bug_status=PASSES_QA&component=libguestfs&field0-0-0=cf_devel_whiteboard&list_id=2137003&product=Virtualization%20Tools&query_format=advanced&type0-0-0=anywords&value0-0-0=1.34 For a list of all bugs, go to: https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
On Tuesday, 12 July 2016 20:37:56 CEST Richard W.M. Jones wrote:
Libguestfs 1.32 was released on 2016-01-06, which is over 6 months ago. In fact the previous stable version of libguestfs (1.30) was released on 2015-07-21, almost exactly 12 months ago. Are we heading for a 6 month release cycle? Not officially. Anyway, I would like you to think about what needs work for the next stable 1.34 release.
Any new APIs added in the 1.33 cycle will become supported and guaranteed when we release 1.34, so we need to check those. See:
git diff 1.32.0 -- generator/actions.ml
Please follow-up also if there are features / blockers / bugs that need to be addressed for 1.34.
I'm working on a small API to handle the system ID of LVMs, which is so far the only thing I'd like to have in 1.34. When where you planning to release? -- Pino Toscano
On Fri, Jul 22, 2016 at 11:15:55AM +0200, Pino Toscano wrote:
On Tuesday, 12 July 2016 20:37:56 CEST Richard W.M. Jones wrote:
Libguestfs 1.32 was released on 2016-01-06, which is over 6 months ago. In fact the previous stable version of libguestfs (1.30) was released on 2015-07-21, almost exactly 12 months ago. Are we heading for a 6 month release cycle? Not officially. Anyway, I would like you to think about what needs work for the next stable 1.34 release.
Any new APIs added in the 1.33 cycle will become supported and guaranteed when we release 1.34, so we need to check those. See:
git diff 1.32.0 -- generator/actions.ml
Please follow-up also if there are features / blockers / bugs that need to be addressed for 1.34.
I'm working on a small API to handle the system ID of LVMs, which is so far the only thing I'd like to have in 1.34.
When where you planning to release?
Probably not in the next 2 weeks since I'm on holiday part of next week and then at a conference the week after. It would be good to do it straight after that, so let's aim for the week beginning Monday, 8th August 2016. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
On Fri, Jul 22, 2016 at 10:25:54AM +0100, Richard W.M. Jones wrote:
On Fri, Jul 22, 2016 at 11:15:55AM +0200, Pino Toscano wrote:
On Tuesday, 12 July 2016 20:37:56 CEST Richard W.M. Jones wrote:
Libguestfs 1.32 was released on 2016-01-06, which is over 6 months ago. In fact the previous stable version of libguestfs (1.30) was released on 2015-07-21, almost exactly 12 months ago. Are we heading for a 6 month release cycle? Not officially. Anyway, I would like you to think about what needs work for the next stable 1.34 release.
Any new APIs added in the 1.33 cycle will become supported and guaranteed when we release 1.34, so we need to check those. See:
git diff 1.32.0 -- generator/actions.ml
Please follow-up also if there are features / blockers / bugs that need to be addressed for 1.34.
I'm working on a small API to handle the system ID of LVMs, which is so far the only thing I'd like to have in 1.34.
When where you planning to release?
Probably not in the next 2 weeks since I'm on holiday part of next week and then at a conference the week after. It would be good to do it straight after that, so let's aim for the week beginning Monday, 8th August 2016.
Another related point about this release. I think we should switch back to Transifex (from Zanata currently). The obvious reason is that Transifex has a good community who actually provided plentiful translations, at least for the simple strings (no one translates the long manual page paragraphs, but I wasn't expecting that). Zanata, well, nothing much really. Also the Zanata client tools suck. We could do this either before or after the 1.34 release (or not at all). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/
On Saturday, 23 July 2016 23:27:30 CEST Richard W.M. Jones wrote:
Another related point about this release. I think we should switch back to Transifex (from Zanata currently).
The obvious reason is that Transifex has a good community who actually provided plentiful translations, at least for the simple strings (no one translates the long manual page paragraphs, but I wasn't expecting that). Zanata, well, nothing much really.
Note that Transifex is only a single instance, while Zanata has different installations; we are using the Fedora instance, so we get mostly Fedora translators. An idea could be move to the generic Zanata instance on zanata.org, i.e. https://translate.zanata.org/ (which allows login using a Fedora FAS, so the current translators could keep contributing without extra burden). Also, what about trying to advertize it more (e.g. blog entry, post on devel@fedora, etc)?
Also the Zanata client tools suck.
What's the problem with it? I didn't use it much, but I don't recall particular issues. Also, Transifex is proprietary software (closed since 2013), which IMHO is a minus point for it. -- Pino Toscano
On Tue, Jul 26, 2016 at 11:02:40AM +0200, Pino Toscano wrote:
On Saturday, 23 July 2016 23:27:30 CEST Richard W.M. Jones wrote:
Another related point about this release. I think we should switch back to Transifex (from Zanata currently).
The obvious reason is that Transifex has a good community who actually provided plentiful translations, at least for the simple strings (no one translates the long manual page paragraphs, but I wasn't expecting that). Zanata, well, nothing much really.
Note that Transifex is only a single instance, while Zanata has different installations; we are using the Fedora instance, so we get mostly Fedora translators. An idea could be move to the generic Zanata instance on zanata.org, i.e. https://translate.zanata.org/ (which allows login using a Fedora FAS, so the current translators could keep contributing without extra burden).
OK I will try this one. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
On Tue, Jul 26, 2016 at 11:19:38AM +0100, Richard W.M. Jones wrote:
On Tue, Jul 26, 2016 at 11:02:40AM +0200, Pino Toscano wrote:
On Saturday, 23 July 2016 23:27:30 CEST Richard W.M. Jones wrote:
Another related point about this release. I think we should switch back to Transifex (from Zanata currently).
The obvious reason is that Transifex has a good community who actually provided plentiful translations, at least for the simple strings (no one translates the long manual page paragraphs, but I wasn't expecting that). Zanata, well, nothing much really.
Note that Transifex is only a single instance, while Zanata has different installations; we are using the Fedora instance, so we get mostly Fedora translators. An idea could be move to the generic Zanata instance on zanata.org, i.e. https://translate.zanata.org/ (which allows login using a Fedora FAS, so the current translators could keep contributing without extra burden).
OK I will try this one.
The problem is that the translation memory isn't shared between Zanata instances (unbelievably, but that appears to be the case). So all this achieves is to split the effort. Unless there is some way to combine translations, resolve conflicts and so on, which there doesn't seem to be. I'm going to have another look at Transifex. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
On Fri, Jul 22, 2016 at 10:25:54AM +0100, Richard W.M. Jones wrote:
On Fri, Jul 22, 2016 at 11:15:55AM +0200, Pino Toscano wrote:
On Tuesday, 12 July 2016 20:37:56 CEST Richard W.M. Jones wrote:
Libguestfs 1.32 was released on 2016-01-06, which is over 6 months ago. In fact the previous stable version of libguestfs (1.30) was released on 2015-07-21, almost exactly 12 months ago. Are we heading for a 6 month release cycle? Not officially. Anyway, I would like you to think about what needs work for the next stable 1.34 release.
Any new APIs added in the 1.33 cycle will become supported and guaranteed when we release 1.34, so we need to check those. See:
git diff 1.32.0 -- generator/actions.ml
Please follow-up also if there are features / blockers / bugs that need to be addressed for 1.34.
I'm working on a small API to handle the system ID of LVMs, which is so far the only thing I'd like to have in 1.34.
When where you planning to release?
Probably not in the next 2 weeks since I'm on holiday part of next week and then at a conference the week after. It would be good to do it straight after that, so let's aim for the week beginning Monday, 8th August 2016.
So that being this week, are we ready for a 1.34 release? I'd like to get Tomáš's 2 x patches in. I think that's everything? - - - - For 1.35, I'd like to look again at: - lkl (https://github.com/rwmjones/libguestfs/tree/lkl) - rewriting inspection (https://github.com/rwmjones/libguestfs/tree/inspection-expert-system) - fixing qemu / using sqlite (https://www.redhat.com/archives/libguestfs/2016-May/msg00210.html) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
participants (2)
-
Pino Toscano -
Richard W.M. Jones