From ptoscano at redhat.com Thu May 14 15:28:29 2020 From: ptoscano at redhat.com (Pino Toscano) Date: Thu, 14 May 2020 17:28:29 +0200 Subject: Using gitlab labels for issues and MRs Message-ID: <2036133.H4XtUMK01Q@lindworm.usersys.redhat.com> Hi, now that we've been using gitlab as primary source for issues and merge requests, maybe we can start using labels to categorize them. I never used them myself, so personally it would be a small thing to learn; considering the traffic of libosinfo issues & MRs is not high, I think we could manage to use them. What do you guys think about this? If you think it is worth, we can define them organization-wide, and my proposals are the following: - tests -- for things related mainly to tests/test suite - osxml -- mainly for the OS XML files in osinfo-db, including changes to the schema - unattented-install -- for anything related to unattended installation (scripts, API, tooling, etc) - tools -- for things related to tools, be it osinfo-db-tools or the ones in libosinfo - ci -- for CI config or scripts used by CI - api -- mainly for libosinfo changes that require new public APIs Of course the above list is not comprehensive, however IMHO it can be a good start. -- Pino Toscano -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From felipeborges at gnome.org Thu May 14 15:33:53 2020 From: felipeborges at gnome.org (Felipe Borges) Date: Thu, 14 May 2020 17:33:53 +0200 Subject: Using gitlab labels for issues and MRs In-Reply-To: <2036133.H4XtUMK01Q@lindworm.usersys.redhat.com> References: <2036133.H4XtUMK01Q@lindworm.usersys.redhat.com> Message-ID: Hi! On Thu, May 14, 2020 at 5:30 PM Pino Toscano wrote: > > Hi, > > now that we've been using gitlab as primary source for issues and merge > requests, maybe we can start using labels to categorize them. > I never used them myself, so personally it would be a small thing to > learn; considering the traffic of libosinfo issues & MRs is not high, > I think we could manage to use them. What do you guys think about this? Good idea. > > If you think it is worth, we can define them organization-wide, and > my proposals are the following: > - tests -- for things related mainly to tests/test suite > - osxml -- mainly for the OS XML files in osinfo-db, including changes > to the schema > - unattented-install -- for anything related to unattended installation > (scripts, API, tooling, etc) > - tools -- for things related to tools, be it osinfo-db-tools or the > ones in libosinfo > - ci -- for CI config or scripts used by CI > - api -- mainly for libosinfo changes that require new public APIs > > Of course the above list is not comprehensive, however IMHO it can be > a good start. Have you considered using GitLab labels for enforcing the development workflow? I mean by adding labels such as "needs-work", "needs-review", "needs-information", etc.. Cheers! Felipe. > > -- > Pino Toscano From berrange at redhat.com Thu May 14 15:49:55 2020 From: berrange at redhat.com (Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?=) Date: Thu, 14 May 2020 16:49:55 +0100 Subject: Using gitlab labels for issues and MRs In-Reply-To: <2036133.H4XtUMK01Q@lindworm.usersys.redhat.com> References: <2036133.H4XtUMK01Q@lindworm.usersys.redhat.com> Message-ID: <20200514154955.GM1280939@redhat.com> On Thu, May 14, 2020 at 05:28:29PM +0200, Pino Toscano wrote: > Hi, > > now that we've been using gitlab as primary source for issues and merge > requests, maybe we can start using labels to categorize them. > I never used them myself, so personally it would be a small thing to > learn; considering the traffic of libosinfo issues & MRs is not high, > I think we could manage to use them. What do you guys think about this? Yes, I think labels are a good thing for initial quick triage of incoming bugs. > > If you think it is worth, we can define them organization-wide, and > my proposals are the following: > - tests -- for things related mainly to tests/test suite > - osxml -- mainly for the OS XML files in osinfo-db, including changes > to the schema > - unattented-install -- for anything related to unattended installation > (scripts, API, tooling, etc) > - tools -- for things related to tools, be it osinfo-db-tools or the > ones in libosinfo > - ci -- for CI config or scripts used by CI > - api -- mainly for libosinfo changes that require new public APIs > > Of course the above list is not comprehensive, however IMHO it can be > a good start. Yep that's all sensible stuff. For libvirt I figured it was useful to distinguish different types of request too - bug - undesirable behaviour - enhancement - request for new feature - documentation - improvement to docs - support - end user usage query - discussion - some topic focused discussion (ie this email thread :-) Finally, I also created "bitesizedtask" as a simple thing that newbies can tackle, and "critical" for something that is high priority to address BTW, you can create labels at the organization level and they apply to all projects. So these I created at the org https://gitlab.com/groups/libvirt/-/labels and then others I created at the project https://gitlab.com/libvirt/libvirt/-/labels I imagine the ones you suggest are probably mostly project level Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| From ptoscano at redhat.com Mon May 18 07:01:03 2020 From: ptoscano at redhat.com (Pino Toscano) Date: Mon, 18 May 2020 09:01:03 +0200 Subject: Using gitlab labels for issues and MRs In-Reply-To: References: <2036133.H4XtUMK01Q@lindworm.usersys.redhat.com> Message-ID: <1812192.uFLHcmXXNr@lindworm.usersys.redhat.com> On Thursday, 14 May 2020 17:33:53 CEST Felipe Borges wrote: > Have you considered using GitLab labels for enforcing the development > workflow? No, I haven't :) As I said, I don't have any experience in working with labels myself, only saw them used in projects where I sent patches to. > I mean by adding labels such as "needs-work", "needs-review", > "needs-information", etc.. Hm most probably because of my lack of experience I do not see the immediate need for all of them, especially that the team is small, and there are is not an high traffic in issues and MRs. However I do find "needs-information" and "needs-work" useful though, I'll add them to my initial list. Thanks, -- Pino Toscano -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From ptoscano at redhat.com Mon May 18 07:08:35 2020 From: ptoscano at redhat.com (Pino Toscano) Date: Mon, 18 May 2020 09:08:35 +0200 Subject: Using gitlab labels for issues and MRs In-Reply-To: <20200514154955.GM1280939@redhat.com> References: <2036133.H4XtUMK01Q@lindworm.usersys.redhat.com> <20200514154955.GM1280939@redhat.com> Message-ID: <12928650.n8AD0tMldy@lindworm.usersys.redhat.com> On Thursday, 14 May 2020 17:49:55 CEST Daniel P. Berrang? wrote: > For libvirt I figured it was useful to distinguish different types of > request too > > - bug - undesirable behaviour > - enhancement - request for new feature > - documentation - improvement to docs > - support - end user usage query > - discussion - some topic focused discussion (ie this email thread :-) Interesting, that means categorizing them also from a "different axis". - "bug" vs "enhancement": I'm not sure we need both, maybe we can use only "enhancement" to replace the "RFE" prefix used in issues - "documentation": definitely something I had in mind, apparently forgot to add it to my list -- done now - "support": I think that user questions (neither bugs nor RFEs) should be closed, and redirecting users to this list; I personally do not like how sometimes the issue trackers in github/gitlab projects turn into user forums, and it becomes really hard to look for issues - "discussion": similar issue than "support" IMHO > BTW, you can create labels at the organization level and they apply to > all projects. So these I created at the org > > https://gitlab.com/groups/libvirt/-/labels > > and then others I created at the project > > https://gitlab.com/libvirt/libvirt/-/labels > > I imagine the ones you suggest are probably mostly project level Yes, that's what I had in mind. Thanks, -- Pino Toscano -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From berrange at redhat.com Mon May 18 09:19:56 2020 From: berrange at redhat.com (Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?=) Date: Mon, 18 May 2020 10:19:56 +0100 Subject: Using gitlab labels for issues and MRs In-Reply-To: <12928650.n8AD0tMldy@lindworm.usersys.redhat.com> References: <2036133.H4XtUMK01Q@lindworm.usersys.redhat.com> <20200514154955.GM1280939@redhat.com> <12928650.n8AD0tMldy@lindworm.usersys.redhat.com> Message-ID: <20200518091956.GB1430944@redhat.com> On Mon, May 18, 2020 at 09:08:35AM +0200, Pino Toscano wrote: > On Thursday, 14 May 2020 17:49:55 CEST Daniel P. Berrang? wrote: > > For libvirt I figured it was useful to distinguish different types of > > request too > > > > - bug - undesirable behaviour > > - enhancement - request for new feature > > - documentation - improvement to docs > > - support - end user usage query > > - discussion - some topic focused discussion (ie this email thread :-) > > Interesting, that means categorizing them also from a "different axis". > > - "bug" vs "enhancement": I'm not sure we need both, maybe we can use > only "enhancement" to replace the "RFE" prefix used in issues I included bug because I think it is desirable to have every single issue tagged with at least 1 of these five tags. This makes it easy to identify issues which have not yet been triaged by anyone. If we don't tag issues as "bug", then we can't tell if it is a new issue no one has looked at, or if it is a issue that is considered a bug. > - "documentation": definitely something I had in mind, apparently forgot > to add it to my list -- done now > > - "support": I think that user questions (neither bugs nor RFEs) should > be closed, and redirecting users to this list; I personally do not > like how sometimes the issue trackers in github/gitlab projects turn > into user forums, and it becomes really hard to look for issues We don't get very many such requests in libosinfo AFAICT, so I don't think it'll make a problem using the issue tracker. The line between bug & support request is often not so obvious when first filing, so it is natural for users to use the issue tracker. > - "discussion": similar issue than "support" IMHO I guess this was more about developers discussing design options. The reason to have this in the issue tracker, is that the discussion will typically lead to one or more RFEs and bug reports, and thus the discussion issue becomes a tracker that links to all the pieces of work needing doing. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| From felipe10borges at gmail.com Tue May 26 14:05:05 2020 From: felipe10borges at gmail.com (Felipe Borges) Date: Tue, 26 May 2020 16:05:05 +0200 Subject: State "bios" firmware support for OSes Message-ID: Hi everyone, We recently landed EFI support in GNOME Boxes where we create guests with "firmware = efi" by default when libosinfo reports that the OS supports it. This has worked great except for the regression with snapshots. Long story short, internal snapshots won't work with EFI, external snapshots won't allow our users to revert their domain to a certain snapshot. For this reason, the Boxes designers and I concluded that the best approach for us here would be to only create EFI guests for OSes that REQUIRE it. If an OS can still boot with the legacy "bios" we should go for it, since it maintains our Snapshot management functionality. The reason I am emailing libosinfo about this is to assess whether you folk would be open to having me adding to the OSes that support it (some of them already state support for EFI). Since the API returns a list of Osinfo.Firmware objects, we won't need any more work on libosinfo side in order to implement what we need in Boxes. All in all, adding to some OSes would be something you'd accept? Cheers, Felipe. From berrange at redhat.com Tue May 26 14:09:46 2020 From: berrange at redhat.com (Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?=) Date: Tue, 26 May 2020 15:09:46 +0100 Subject: State "bios" firmware support for OSes In-Reply-To: References: Message-ID: <20200526140946.GH2496524@redhat.com> On Tue, May 26, 2020 at 04:05:05PM +0200, Felipe Borges wrote: > Hi everyone, > > We recently landed EFI support in GNOME Boxes where we create guests > with "firmware = efi" by default when libosinfo reports that the OS > supports it. This has worked great except for the regression with > snapshots. Long story short, internal snapshots won't work with EFI, > external snapshots won't allow our users to revert their domain to a > certain snapshot. > > For this reason, the Boxes designers and I concluded that the best > approach for us here would be to only create EFI guests for OSes that > REQUIRE it. If an OS can still boot with the legacy "bios" we should > go for it, since it maintains our Snapshot management functionality. > > The reason I am emailing libosinfo about this is to assess whether you > folk would be open to having me adding type="bios"/> to the OSes that support it (some of them already state > support for EFI). > > Since the API returns a list of Osinfo.Firmware objects, we won't need > any more work on libosinfo side in order to implement what we need in > Boxes. > > All in all, adding to some OSes > would be something you'd accept? Yes, I was pretty much expecting we would need to add such info at some point. Might it be easier to ask which OS do NOT support BIOS ? IOW, should we blindly add it to essentially every single OS, except for the very few known to not support it any more. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| From fidencio at redhat.com Tue May 26 22:28:25 2020 From: fidencio at redhat.com (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Wed, 27 May 2020 00:28:25 +0200 Subject: State "bios" firmware support for OSes In-Reply-To: References: Message-ID: Felipe, On Tue, May 26, 2020 at 4:06 PM Felipe Borges wrote: > > Hi everyone, > > We recently landed EFI support in GNOME Boxes where we create guests > with "firmware = efi" by default when libosinfo reports that the OS > supports it. This has worked great except for the regression with > snapshots. Long story short, internal snapshots won't work with EFI, > external snapshots won't allow our users to revert their domain to a > certain snapshot. > > For this reason, the Boxes designers and I concluded that the best > approach for us here would be to only create EFI guests for OSes that > REQUIRE it. If an OS can still boot with the legacy "bios" we should > go for it, since it maintains our Snapshot management functionality. > > The reason I am emailing libosinfo about this is to assess whether you > folk would be open to having me adding type="bios"/> to the OSes that support it (some of them already state > support for EFI). > > Since the API returns a list of Osinfo.Firmware objects, we won't need > any more work on libosinfo side in order to implement what we need in > Boxes. > > All in all, adding to some OSes > would be something you'd accept? I'd take the opposite direction, Felipe. Although our schema supports , as you can see here[0], I'd rather assume that all OSes support BIOS, unless something like is set, and we're prepared for this[1]. So, what about changing the check we do on Boxes[2] to something like: ``` if (firmware.get_firmware_type () == "bios" && !firmware.is_supported ()) return true ``` That should do the trick. [0]: https://gitlab.com/libosinfo/osinfo-db/-/blob/master/data/schema/osinfo.rng.in#L936 [1]: https://gitlab.com/libosinfo/osinfo-db/-/blob/master/data/schema/osinfo.rng.in#L596 [2]: https://gitlab.gnome.org/GNOME/gnome-boxes/-/blob/master/src/installer-media.vala#L65 Best Regards, -- Fabiano Fid?ncio From fidencio at redhat.com Tue May 26 22:30:00 2020 From: fidencio at redhat.com (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Wed, 27 May 2020 00:30:00 +0200 Subject: State "bios" firmware support for OSes In-Reply-To: <20200526140946.GH2496524@redhat.com> References: <20200526140946.GH2496524@redhat.com> Message-ID: On Tue, May 26, 2020 at 4:10 PM Daniel P. Berrang? wrote: > > On Tue, May 26, 2020 at 04:05:05PM +0200, Felipe Borges wrote: > > Hi everyone, > > > > We recently landed EFI support in GNOME Boxes where we create guests > > with "firmware = efi" by default when libosinfo reports that the OS > > supports it. This has worked great except for the regression with > > snapshots. Long story short, internal snapshots won't work with EFI, > > external snapshots won't allow our users to revert their domain to a > > certain snapshot. > > > > For this reason, the Boxes designers and I concluded that the best > > approach for us here would be to only create EFI guests for OSes that > > REQUIRE it. If an OS can still boot with the legacy "bios" we should > > go for it, since it maintains our Snapshot management functionality. > > > > The reason I am emailing libosinfo about this is to assess whether you > > folk would be open to having me adding > type="bios"/> to the OSes that support it (some of them already state > > support for EFI). > > > > Since the API returns a list of Osinfo.Firmware objects, we won't need > > any more work on libosinfo side in order to implement what we need in > > Boxes. > > > > All in all, adding to some OSes > > would be something you'd accept? > > Yes, I was pretty much expecting we would need to add such info at some > point. > > Might it be easier to ask which OS do NOT support BIOS ? > > IOW, should we blindly add it to essentially every single OS, except for > the very few known to not support it any more. Oh! I should have read the whole thread before answering. Well, +1 for this approach. Best Regards, -- Fabiano Fid?ncio From fidencio at redhat.com Sat May 30 09:09:22 2020 From: fidencio at redhat.com (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Sat, 30 May 2020 11:09:22 +0200 Subject: ANNOUNCE: osinfo-db-tools 1.8.0 release Message-ID: I am happy to announce a new release of osinfo-db-tools, version 1.8.0: https://releases.pagure.org/libosinfo/osinfo-db-tools-1.8.0.tar.xz This is signed with key 09B9 C8FF 223E F113 AFA0 6A39 EE92 6C2B DACC 177B (4096R) https://releases.pagure.org/libosinfo/osinfo-db-tools-1.8.0.tar.xz.asc All historical releases are available from: http://libosinfo.org/download/ Changes in this release include: - Several CI improvements - Several release scripts improvements - Several translations improvements - Several syntax-check improvements Thanks to everyone who contributed to this release Best Regards, -- Fabiano Fid?ncio From fidencio at redhat.com Sat May 30 09:09:33 2020 From: fidencio at redhat.com (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Sat, 30 May 2020 11:09:33 +0200 Subject: ANNOUNCE: libosinfo 1.8.0 release Message-ID: I am happy to announce a new release of libosinfo, version 1.8.0: https://releases.pagure.org/libosinfo/libosinfo-1.8.0.tar.xz This is signed with key 09B9 C8FF 223E F113 AFA0 6A39 EE92 6C2B DACC 177B (4096R) https://releases.pagure.org/libosinfo/libosinfo-1.8.0.tar.xz.asc All historical releases are available from: http://libosinfo.org/download/ Changes in this release include: - Several CI improvements - Several release scripts improvements - Several translations improvements - Several syntax-check improvements - Code cleanup in order to modernize the GObject usage - Add API to get whether a firmware is supported or not - Add API to get "cloud-image-username" Thanks to everyone who contributed to this release Best Regards, -- Fabiano Fid?ncio