Hi, based on request of cschaller, I'm sending the proposed list of Qt/Qt5 packages to be included in Fedora Workstation:
qt qt-x11 qt-settings
qt5-qtbase qt5-qtimageformats qt5-qtsvg qt5-qtx11extras qt5-qtxmlpatterns qt5-qtdeclarative qt5-qtquickcontrols qt5-qtdoc qt5-qtconnectivity qt5-qtmultimedia qt5-qtgraphicaleffects
(you can see the dep chain of qt5 packages here: https://fedoraproject.org/wiki/KDE_updates)
On Thu, 2014-05-29 at 14:32 +0200, Lukáš Tinkl wrote:
Hi, based on request of cschaller, I'm sending the proposed list of Qt/Qt5 packages to be included in Fedora Workstation:
qt qt-x11 qt-settings
qt5-qtbase qt5-qtimageformats qt5-qtsvg qt5-qtx11extras qt5-qtxmlpatterns qt5-qtdeclarative qt5-qtquickcontrols qt5-qtdoc qt5-qtconnectivity qt5-qtmultimedia qt5-qtgraphicaleffects
(you can see the dep chain of qt5 packages here: https://fedoraproject.org/wiki/KDE_updates)
Thanks, Lukas
The current package list has the following already:
qt qt5-qtbase qt5-qtbase-gui qt5-qtdeclarative qt5-qtxmlpatterns qt-settings qt-x11
I'll make sure we add the rest. I've attached the full, current package list of the workstation iso (as of yesterday); in case somebody wants to suggests other additions or changes.
Matthias
Hi Matthias and Lukas, Thanks for this. Although I think we should as a formality vote on this addition, so that we have our paper trail in order.
So I hereby ask the Working Group to vote on the inclusion of the package list provided by Lukas.
To start with myself: I vote in favour of adding these packages.
Christian
----- Original Message -----
From: "Matthias Clasen" mclasen@redhat.com To: desktop@lists.fedoraproject.org Sent: Thursday, May 29, 2014 4:20:43 PM Subject: Re: List of Qt/Qt5 packages for Fedora WS
On Thu, 2014-05-29 at 14:32 +0200, Lukáš Tinkl wrote:
Hi, based on request of cschaller, I'm sending the proposed list of Qt/Qt5 packages to be included in Fedora Workstation:
qt qt-x11 qt-settings
qt5-qtbase qt5-qtimageformats qt5-qtsvg qt5-qtx11extras qt5-qtxmlpatterns qt5-qtdeclarative qt5-qtquickcontrols qt5-qtdoc qt5-qtconnectivity qt5-qtmultimedia qt5-qtgraphicaleffects
(you can see the dep chain of qt5 packages here: https://fedoraproject.org/wiki/KDE_updates)
Thanks, Lukas
The current package list has the following already:
qt qt5-qtbase qt5-qtbase-gui qt5-qtdeclarative qt5-qtxmlpatterns qt-settings qt-x11
I'll make sure we add the rest. I've attached the full, current package list of the workstation iso (as of yesterday); in case somebody wants to suggests other additions or changes.
Matthias
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Thu, May 29, 2014 at 10:29 AM, Christian Schaller cschalle@redhat.com wrote:
Hi Matthias and Lukas, Thanks for this. Although I think we should as a formality vote on this addition, so that we have our paper trail in order.
So I hereby ask the Working Group to vote on the inclusion of the package list provided by Lukas.
To start with myself: I vote in favour of adding these packages.
I also vote in favour.
josh
On Thu, May 29, 2014 at 10:35 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, May 29, 2014 at 10:29 AM, Christian Schaller cschalle@redhat.com wrote:
Hi Matthias and Lukas, Thanks for this. Although I think we should as a formality vote on this addition, so that we have our paper trail in order.
So I hereby ask the Working Group to vote on the inclusion of the package list provided by Lukas.
To start with myself: I vote in favour of adding these packages.
I also vote in favour.
OK, this is pretty sad. Only 2 explicit votes from the entire WG? I'm going to assume that Lukáš at least has an implicit +1 given that he posted the list originally. Matthias likely also has an implicit +1.
However, the rest of you have failed entirely. Why is that? Where are the votes? How hard is it to read an email and reply with "+1" or a dissenting opinion?
Please, help us out here. This WG, out of all the existing WGs, is currently suffering from a lack of transparency. If you don't want to be on the WG, just let me know and we'll find a replacement. Otherwise, please vote.
josh
On Tue, Jun 3, 2014 at 7:10 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, May 29, 2014 at 10:35 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, May 29, 2014 at 10:29 AM, Christian Schaller cschalle@redhat.com wrote:
Hi Matthias and Lukas, Thanks for this. Although I think we should as a formality vote on this addition, so that we have our paper trail in order.
So I hereby ask the Working Group to vote on the inclusion of the package list provided by Lukas.
To start with myself: I vote in favour of adding these packages.
I also vote in favour.
OK, this is pretty sad. Only 2 explicit votes from the entire WG? I'm going to assume that Lukáš at least has an implicit +1 given that he posted the list originally. Matthias likely also has an implicit +1.
However, the rest of you have failed entirely. Why is that? Where are the votes? How hard is it to read an email and reply with "+1" or a dissenting opinion?
"Many of our decisions can be made through "lazy consensus". Under this model, an intended action is announced on the mailing list, discussed, and in the absence of a group of dissenting contributors within a few days, simply done. " [1]
Wouldn't this fall into this or where are the objections? (Have not seen any) ... also:
"For bigger issues, where there may be disagreement, or where there is long-term impact, or where an action may not easily be undone, we will put forth a formal proposal on the mailing list with a "[Proposal for Vote] header in the email Subject: field. Working group members can vote +1 to approve, -1 to disagree, or 0 to abstain; a majority vote is necessary for a measure to pass with abstain votes not being included in the count. Members have one week to record their votes on an official proposal. Members who do not vote within the voting period implicitly abstain. Non-members may comment on the item and (of course) discuss on the mailing list, but are asked to refrain from putting votes on official proposal threads. " [1]
Is this no longer how things work? No vote in one week is supposed to mean abstain also the thread does not have the "[Proposal for Vote]" header in the subject.
So the process isn't working? Should we change it or are people simply using the "lazy consensus" rule?
1: https://fedoraproject.org/wiki/Workstation/Governance#Making_Decisions
On Tue, Jun 3, 2014 at 5:35 PM, drago01 drago01@gmail.com wrote:
On Tue, Jun 3, 2014 at 7:10 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, May 29, 2014 at 10:35 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, May 29, 2014 at 10:29 AM, Christian Schaller cschalle@redhat.com wrote:
Hi Matthias and Lukas, Thanks for this. Although I think we should as a formality vote on this addition, so that we have our paper trail in order.
So I hereby ask the Working Group to vote on the inclusion of the package list provided by Lukas.
To start with myself: I vote in favour of adding these packages.
I also vote in favour.
OK, this is pretty sad. Only 2 explicit votes from the entire WG? I'm going to assume that Lukáš at least has an implicit +1 given that he posted the list originally. Matthias likely also has an implicit +1.
However, the rest of you have failed entirely. Why is that? Where are the votes? How hard is it to read an email and reply with "+1" or a dissenting opinion?
"Many of our decisions can be made through "lazy consensus". Under this model, an intended action is announced on the mailing list, discussed, and in the absence of a group of dissenting contributors within a few days, simply done. " [1]
Wouldn't this fall into this or where are the objections? (Have not seen any) ... also:
A WG member called for a formal vote. That would imply people should actually vote.
"For bigger issues, where there may be disagreement, or where there is long-term impact, or where an action may not easily be undone, we will put forth a formal proposal on the mailing list with a "[Proposal for Vote] header in the email Subject: field. Working group members can vote +1 to approve, -1 to disagree, or 0 to abstain; a majority vote is necessary for a measure to pass with abstain votes not being included in the count. Members have one week to record their votes on an official proposal. Members who do not vote within the voting period implicitly abstain. Non-members may comment on the item and (of course) discuss on the mailing list, but are asked to refrain from putting votes on official proposal threads. " [1]
Is this no longer how things work? No vote in one week is supposed to mean abstain also the thread does not have the "[Proposal for Vote]" header in the subject.
The header was missing. To be honest, I doubt it would have made a difference.
So the process isn't working? Should we change it or are people simply using the "lazy consensus" rule?
Frankly, I think the process hasn't worked at all. It might be great for reducing overhead, but in hindsight it really hurts transparency. We already had a similar thread on this and we created a trac instance, which was at least a start but not a resounding success. In the same thread we floated the idea of doing public IRC meetings. We should probably follow through with that.
Even ignoring votes, there is very very little in the way of public participation from WG members. I didn't even get replies from many of them when I asked if they still wanted to be on the WG. Whether that's because it's still unclear what we're doing or because they don't read their desktop folder or because of apathy, I have no idea. Whatever the reason, it gives an outward appearance of nothing being done or (with more tinfoil) everything being done behind closed doors. Not helpful.
josh
Matthias Clasen wrote:
fcoe-utils lldpad
These seem more aimed at the Server product. Sure, anaconda pulls these in for installation support, but do you expect the WS product to be installed on such a crazy network? Could anaconda make these optional?
NetworkManager-pptp NetworkManager-pptp-gnome ppp pptp
Do networks that use PPTP still exist? I hope not. We shouldn't encourage unsecure connection types.
iscsi-initiator-utils iscsi-initiator-utils-iscsiuio radvd
I see libvirt (and anaconda for iSCSI) requires these and it's unfortunate. All you're missing is dhcpd/bind and the WS product is basically the Server product.
Is virtualization important to have in the base product package list? Not every developer uses the same virt software. Virt software is more of an "add-on" in that the WS product's goal of being a foundation for building Fedora/Linux applications isn't met by including libvirt by default. Yes, it's nice to test applications and yes, I use visualization myself (not libvirt), but my concern still stands. Perhaps this could be handled by the developer assistant.
Would it be appropriate to include "devhelp" in the package list? We're not shipping GTK/Qt docs, but should we?
Out of the box the WS product cannot produce an application. RPMs cannot be built (rpm-build, mock?). There is no C compiler. What about "-devel" packages? (too heavy for download, USB, DVD?) Is this what the "Developer assistant" application will deal with?
On Thu, May 29, 2014 at 6:21 PM, Michael Cronenworth mike@cchtml.com wrote:
Matthias Clasen wrote:
fcoe-utils
lldpad
These seem more aimed at the Server product. Sure, anaconda pulls these in for installation support, but do you expect the WS product to be installed on such a crazy network? Could anaconda make these optional?
I doubt that you'll be able to convince the Anaconda team to make them optional. I would like to see it happen, but don't get your hopes up.
Do networks that use PPTP still exist? I hope not. We shouldn't encourage unsecure connection types.
Yes, it's still very common
iscsi-initiator-utils iscsi-initiator-utils-iscsiuio
radvd
I see libvirt (and anaconda for iSCSI) requires these and it's unfortunate. All you're missing is dhcpd/bind and the WS product is basically the Server product.
Is virtualization important to have in the base product package list? Not every developer uses the same virt software. Virt software is more of an "add-on" in that the WS product's goal of being a foundation for building Fedora/Linux applications isn't met by including libvirt by default. Yes, it's nice to test applications and yes, I use visualization myself (not libvirt), but my concern still stands. Perhaps this could be handled by the developer assistant.
Personally I think having virtualization that works out-of-the-box is an excellent selling point and we should keep gnome-boxes (and libvirt) by default. I'm not sure why it needs iscsi tho.
Would it be appropriate to include "devhelp" in the package list? We're not shipping GTK/Qt docs, but should we?
Yes, I was going to add it tomorrow when I make the comps group. Shipping documentation out of the box is not a good idea because documentation can grow huge. We still need a design on how to install developer documentation. Perhaps devassistant should be doing it, or PackageKit integration from within devhelp.
My idea is that we'll have an item in gnome-software called "Desktop SDK" which will install all headers you need for a basic desktop app, as well as their documentation, and that devhelp will have a link to that if it can't find any documentation. This is just a suggestion tho, as this is a complex problem we really need to think what the proper flow here should be. Until we decide on that in the GNOME desktop level, we should integrate it with DevAssistant instead. I don't think we have enough time for a gnome-level solution for this problem in this cycle, but integrating it in DevAssistant should be easier.
Out of the box the WS product cannot produce an application. RPMs cannot be built (rpm-build, mock?). There is no C compiler. What about "-devel" packages? (too heavy for download, USB, DVD?) Is this what the "Developer assistant" application will deal with?
That's for devassistant to deal with, yes.
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On 05/29/2014 12:27 PM, Elad Alfassa wrote:
On Thu, May 29, 2014 at 6:21 PM, Michael Cronenworth <mike@cchtml.com
I see libvirt (and anaconda for iSCSI) requires these and it's unfortunate. All you're missing is dhcpd/bind and the WS product is basically the Server product. Is virtualization important to have in the base product package list? Not every developer uses the same virt software. Virt software is more of an "add-on" in that the WS product's goal of being a foundation for building Fedora/Linux applications isn't met by including libvirt by default. Yes, it's nice to test applications and yes, I use visualization myself (not libvirt), but my concern still stands. Perhaps this could be handled by the developer assistant.Personally I think having virtualization that works out-of-the-box is an excellent selling point and we should keep gnome-boxes (and libvirt) by default. I'm not sure why it needs iscsi tho.
Libvirt has support for connecting to all sorts of various storage setups, however the functionality is optional and not used by the majority of virt users in fedora. It's possible libvirt could split out the storage drivers into individual modules/rpms like it does for hypervisor drivers, and then boxes etc. could depend on a small subset. But it would require non trivial upstream libvirt work to get there.
- Cole
On Thu, May 29, 2014 at 01:00:27PM -0400, Cole Robinson wrote:
Libvirt has support for connecting to all sorts of various storage setups, however the functionality is optional and not used by the majority of virt users in fedora. It's possible libvirt could split out the storage drivers into individual modules/rpms like it does for hypervisor drivers, and then boxes etc. could depend on a small subset. But it would require non trivial upstream libvirt work to get there.
FWIW... https://bugzilla.redhat.com/show_bug.cgi?id=1012198
Elad Alfassa wrote:
Personally I think having virtualization that works out-of-the-box is an excellent selling point and we should keep gnome-boxes (and libvirt) by default.
Could you provide a reasoning that isn't based on opinion? Based on the WS PRD and other wiki pages virtualization isn't covered by "providing a platform for development of various types of applications."
I also would bet hard cash that outside a subset of Red Hat customers that use libvirt, most people will not use libvirt. Let's drop the FOSS bias and face reality. No offense to the individuals who work on it. If libvirt and it's substantial baggage was dropped it would open up room for docs (GTK2+GTK3 docs are only ~2.5MB each xz compressed) or other packages more valuable to the WS product's mission.
On Thu, May 29, 2014 at 3:16 PM, Michael Cronenworth mike@cchtml.com wrote:
Elad Alfassa wrote:
Personally I think having virtualization that works out-of-the-box is an excellent selling point and we should keep gnome-boxes (and libvirt) by default.
Could you provide a reasoning that isn't based on opinion? Based on the WS PRD and other wiki pages virtualization isn't covered by "providing a platform for development of various types of applications."
Read use-cases 2 and 3 of the PRD. Virtualization is highlighted there.
I also would bet hard cash that outside a subset of Red Hat customers that use libvirt, most people will not use libvirt. Let's drop the FOSS bias and
Now who's reasoning on opinion?
This is Fedora. We don't drop FOSS bias. If there's a problem with a FOSS solution, then in theory it gets reported and fixed.
face reality. No offense to the individuals who work on it. If libvirt and it's substantial baggage was dropped it would open up room for docs (GTK2+GTK3 docs are only ~2.5MB each xz compressed) or other packages more valuable to the WS product's mission.
Space really isn't an issue at the moment.
josh
On 05/29/2014 09:24 PM, Josh Boyer wrote:
On Thu, May 29, 2014 at 3:16 PM, Michael Cronenworth mike@cchtml.com wrote:
Elad Alfassa wrote:
Personally I think having virtualization that works out-of-the-box is an excellent selling point and we should keep gnome-boxes (and libvirt) by default.
Could you provide a reasoning that isn't based on opinion? Based on the WS PRD and other wiki pages virtualization isn't covered by "providing a platform for development of various types of applications."
Read use-cases 2 and 3 of the PRD. Virtualization is highlighted there.
Yes, it's in the PRD and I very much agree that virtualization and well-working gnome-boxes is a must have. But that doesn't mean we have to install everything by default. Not any more, now that we have a working application installer.
In contrary, I would say that we should install _less_ apps by default and instead make sure those extra apps are properly advertised in the application installer and tested and supported.
In the past we needed to install a lot of apps by default to overcome the shortcomings of the installer. This is no longer the case.
Even though we are putting more emphasis and developer effort into producing a good platform for app developers, it doesn't mean we aren't still producing a distro for general consumption. And I'd say that people who need virtualization are more than capable of installing an additional app for that. But people who don't are likely going to find a Boxes launcher confusing.
In general, what I'd like to ship by default is a good base platform. A platform that has enough applications and tools to cover the most common use cases: web browsing, email, document editing; one that supports most common file formats. And most importantly, it needs to come with _excellent_ tools for installing additional applications.
Space really isn't an issue at the moment.
I disagree with that statement. Space and the number of packages always comes with a cost. Sure, it probably won't matter that much for the initial installation as long as it's going to fit on a 2 GB USB stick, but it can matter for updates. Having more packages means updates take longer to install; more downtime while the offline updater runs. Also more packages means more frequent updates, which can be frustrating for users if they are nagged about updating apps they never ever use.
On Wed, Jun 4, 2014 at 7:25 AM, Kalev Lember kalevlember@gmail.com wrote:
On 05/29/2014 09:24 PM, Josh Boyer wrote:
On Thu, May 29, 2014 at 3:16 PM, Michael Cronenworth mike@cchtml.com wrote:
Elad Alfassa wrote:
Personally I think having virtualization that works out-of-the-box is an excellent selling point and we should keep gnome-boxes (and libvirt) by default.
Could you provide a reasoning that isn't based on opinion? Based on the WS PRD and other wiki pages virtualization isn't covered by "providing a platform for development of various types of applications."
Read use-cases 2 and 3 of the PRD. Virtualization is highlighted there.
Yes, it's in the PRD and I very much agree that virtualization and well-working gnome-boxes is a must have. But that doesn't mean we have to install everything by default. Not any more, now that we have a working application installer.
In contrary, I would say that we should install _less_ apps by default and instead make sure those extra apps are properly advertised in the application installer and tested and supported.
In the past we needed to install a lot of apps by default to overcome the shortcomings of the installer. This is no longer the case.
Even though we are putting more emphasis and developer effort into producing a good platform for app developers, it doesn't mean we aren't still producing a distro for general consumption. And I'd say that people who need virtualization are more than capable of installing an additional app for that. But people who don't are likely going to find a Boxes launcher confusing.
I disagree. We aren't targeting people that find virtualization to be a confusing concept. Workstation is targeting developers and students with a reasonable degree of technical competence. I believe working virt out of the box should be installed.
In general, what I'd like to ship by default is a good base platform. A platform that has enough applications and tools to cover the most common use cases: web browsing, email, document editing; one that supports most common file formats. And most importantly, it needs to come with _excellent_ tools for installing additional applications.
I think that describes what the existing desktop spin was aiming for, not what Workstation is setting out to do. Or, more specifically, what you describe is indeed a good base platform and Workstation is a superset of that.
Space really isn't an issue at the moment.
I disagree with that statement. Space and the number of packages always comes with a cost. Sure, it probably won't matter that much for the initial installation as long as it's going to fit on a 2 GB USB stick, but it can matter for updates. Having more packages means updates take longer to install; more downtime while the offline updater runs. Also more packages means more frequent updates, which can be frustrating for users if they are nagged about updating apps they never ever use.
The live iso is ~1.2 GB right now. In the context of having space to fit libvirt/kvm, it's fine.
As for updates, I agree there are too many.
josh
Regarding space, I should remind you all the space is ALWAYS an issue. Downloading 1.2GB can take a long time for people with slow internet connections, or people who pay per byte. It might not be a problem for you personally, but it does affect more people. I think we should try to reduce the initial download size, instead of saying "it's not a problem". True, CDs are a thing of the past, but slow or outrageously priced internet connections still aren't.
On 4 June 2014 12:52, Josh Boyer jwboyer@fedoraproject.org wrote:
We aren't targeting people that find virtualization to be a confusing concept. Workstation is targeting developers and students with a reasonable degree of technical competence. I believe working virt out of the box should be installed. The live iso is ~1.2 GB right now. In the context of having space to
For what it's worth, I consider myself to be firmly in the target audience for WS: I'm a web developer using all Free software and I've been using Linux since about Red Hat 7.
Mostly I use virtualisation to test stuff in MSIE on various flavours of Windows. If GNOME Boxes, libvirt, etc. is installed by default then I'll remove it and install VirtualBox. That's not because I prefer VBox - I don't at all - but because Microsoft provides images for VBox and making them work nicely with libvirt is a hassle I can do without.
Developers are a picky lot; I think generally we'll all prefer having a quick and easy means of finding and installing the stuff we want over having loads of stuff we might need pre-installed: the fewer packages pre-installed, the fewer I have to manually remove because they're not applicable to me.
-- "Racing turtles, the grapefruit is winning..."
On 06/04/2014 02:14 PM, Richard Turner wrote:
Mostly I use virtualisation to test stuff in MSIE on various flavours of Windows. If GNOME Boxes, libvirt, etc. is installed by default then I'll remove it and install VirtualBox. That's not because I prefer VBox - I don't at all - but because Microsoft provides images for VBox and making them work nicely with libvirt is a hassle I can do without.
This is a very good use case, thanks for bringing this up.
Is there anything we could do to make it easier for you? I know VirtualBox distributes their stuff upstream in rpm format, but compiles parts of it (the kernel modules) after installation. Would it make it easier to set up VirtualBox if we included the kernel-devel and gcc packages in the default install?
On Wed, Jun 4, 2014 at 3:01 PM, Kalev Lember kalevlember@gmail.com wrote:
On 06/04/2014 02:14 PM, Richard Turner wrote:
Mostly I use virtualisation to test stuff in MSIE on various flavours of Windows. If GNOME Boxes, libvirt, etc. is installed by default then I'll remove it and install VirtualBox. That's not because I prefer VBox - I don't at all - but because Microsoft provides images for VBox and making them work nicely with libvirt is a hassle I can do without.
This is a very good use case, thanks for bringing this up.
Is there anything we could do to make it easier for you? I know VirtualBox distributes their stuff upstream in rpm format, but compiles parts of it (the kernel modules) after installation. Would it make it easier to set up VirtualBox if we included the kernel-devel and gcc packages in the default install?
On 4 June 2014 14:07, drago01 drago01@gmail.com wrote:
Thanks for raising that bug, and for bringing it to my attention.
-- "Racing turtles, the grapefruit is winning..."
On 4 June 2014 14:01, Kalev Lember kalevlember@gmail.com wrote:
On 06/04/2014 02:14 PM, Richard Turner wrote:
Mostly I use virtualisation to test stuff in MSIE on various flavours of Windows. If GNOME Boxes, libvirt, etc. is installed by default then I'll remove it and install VirtualBox. That's not because I prefer VBox - I don't at all - but because Microsoft provides images for VBox and making them work nicely with libvirt is a hassle I can do without.
This is a very good use case, thanks for bringing this up.
Is there anything we could do to make it easier for you? I know VirtualBox distributes their stuff upstream in rpm format, but compiles parts of it (the kernel modules) after installation. Would it make it easier to set up VirtualBox if we included the kernel-devel and gcc packages in the default install?
It's been quite a while since I needed go install VBox: now that I already have the dependencies installed I can just download and install the RPM from Oracle's site whenever VBox notifies me of an update. However, initially I used instructions from If Not True Then False http://www.if-not-true-then-false.com/2010/install-virtualbox-with-yum-on-fedora-centos-red-hat-rhel/ to install VBox. One can see there that you're right; gcc, kernel-devel, etc. are required for compiling the kernel modules. So, yes, there's certainly scope there to make VBox installation far easier than it currently is.
On Wed, 2014-06-04 at 14:17 +0100, Richard Turner wrote:
It's been quite a while since I needed go install VBox: now that I already have the dependencies installed I can just download and install the RPM from Oracle's site whenever VBox notifies me of an update. However, initially I used instructions from If Not True Then False to install VBox. One can see there that you're right; gcc, kernel-devel, etc. are required for compiling the kernel modules. So, yes, there's certainly scope there to make VBox installation far easier than it currently is.
openSUSE and Debian both have VirtualBox in their FLOSS repos (though it looks like Debian has removed a few files). Is there a particular reason Fedora does not, or is it just that it hasn't been packaged? I've Googled this a few times but found no explanation.
On Wed, Jun 04, 2014 at 09:06:29AM -0500, Michael Catanzaro wrote:
openSUSE and Debian both have VirtualBox in their FLOSS repos (though it looks like Debian has removed a few files). Is there a particular reason Fedora does not, or is it just that it hasn't been packaged? I've Googled this a few times but found no explanation.
It requires out-of-tree kernel modules.
On 6/4/2014 7:06 AM, Michael Catanzaro wrote:
On Wed, 2014-06-04 at 14:17 +0100, Richard Turner wrote:
It's been quite a while since I needed go install VBox: now that I already have the dependencies installed I can just download and install the RPM from Oracle's site whenever VBox notifies me of an update. However, initially I used instructions from If Not True Then False to install VBox. One can see there that you're right; gcc, kernel-devel, etc. are required for compiling the kernel modules. So, yes, there's certainly scope there to make VBox installation far easier than it currently is.
openSUSE and Debian both have VirtualBox in their FLOSS repos (though it looks like Debian has removed a few files). Is there a particular reason Fedora does not, or is it just that it hasn't been packaged? I've Googled this a few times but found no explanation.
Here is my openSUSE-Education 1.3.1 with VirtualBox:
Virtualbox 4.2.18_OSE r88780 with installed extensions (Oracle) 4.2.18-88780 in openSUSE 13.1 1024 / 2 CPU / bridged networking
works with f21(rawhide) boot.iso and workstation-live-x86_64
On Wed, Jun 04, 2014 at 03:01:33PM +0200, Kalev Lember wrote:
Windows. If GNOME Boxes, libvirt, etc. is installed by default then I'll remove it and install VirtualBox. That's not because I prefer VBox - I don't at all - but because Microsoft provides images for VBox and making them work nicely with libvirt is a hassle I can do without.
This is a very good use case, thanks for bringing this up. Is there anything we could do to make it easier for you? I know VirtualBox distributes their stuff upstream in rpm format, but compiles parts of it (the kernel modules) after installation. Would it make it easier to set up VirtualBox if we included the kernel-devel and gcc packages in the default install?
Or alternately, can we make it so those provided VBox images _just work_ with our open virtualization software?
On 4 June 2014 14:36, Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Jun 04, 2014 at 03:01:33PM +0200, Kalev Lember wrote:
Windows. If GNOME Boxes, libvirt, etc. is installed by default then
I'll
remove it and install VirtualBox. That's not because I prefer VBox - I don't at all - but because Microsoft provides images for VBox and
making
them work nicely with libvirt is a hassle I can do without.
This is a very good use case, thanks for bringing this up. Is there anything we could do to make it easier for you? I know VirtualBox distributes their stuff upstream in rpm format, but compiles parts of it (the kernel modules) after installation. Would it make it easier to set up VirtualBox if we included the kernel-devel and gcc packages in the default install?
Or alternately, can we make it so those provided VBox images _just work_ with our open virtualization software?
Yep, that'd be great.
When I first set-up my system I was using libvirt to run a sandbox VM (I needed an Ubuntu server :( ). When I learned of the MSIE VMs and downloaded one I was optimistic about being able to run it using libvirt: those images are OVAs. It took quite some effort to research how to convert the format, and when I finally managed it I had terrible display resolution and Windows was complaining about not being Genuine. All this was incidental to my actual work, so I took the faster route and moved my sandbox VM over to VBox.
I'd happily have continued to use Fedora's default open virtualisation software, except that I had work to do and it wasn't helping me do that.
On Wed, Jun 04, 2014 at 02:49:32PM +0100, Richard Turner wrote:
Or alternately, can we make it so those provided VBox images _just work_ with our open virtualization software?
[...]
I'd happily have continued to use Fedora's default open virtualisation software, except that I had work to do and it wasn't helping me do that.
Hey Fedora Workstation WG members -- is there a good place to track user stories like this? Should they be put in the new trac instance (https://fedorahosted.org/workstation/), or on the wiki?
----- Original Message -----
From: "Matthew Miller" mattdm@fedoraproject.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Wednesday, June 4, 2014 3:36:04 PM Subject: Re: Package List Discussion
On Wed, Jun 04, 2014 at 03:01:33PM +0200, Kalev Lember wrote:
Windows. If GNOME Boxes, libvirt, etc. is installed by default then I'll remove it and install VirtualBox. That's not because I prefer VBox - I don't at all - but because Microsoft provides images for VBox and making them work nicely with libvirt is a hassle I can do without.
This is a very good use case, thanks for bringing this up. Is there anything we could do to make it easier for you? I know VirtualBox distributes their stuff upstream in rpm format, but compiles parts of it (the kernel modules) after installation. Would it make it easier to set up VirtualBox if we included the kernel-devel and gcc packages in the default install?
Or alternately, can we make it so those provided VBox images _just work_ with our open virtualization software?
It is on Zeeshans todo list: https://bugzilla.gnome.org/show_bug.cgi?id=723008
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On 06/04/2014 01:52 PM, Josh Boyer wrote:
I disagree. We aren't targeting people that find virtualization to be a confusing concept. Workstation is targeting developers and students with a reasonable degree of technical competence. I believe working virt out of the box should be installed.
No, sorry, you might have misunderstood the PRD. We aren't producing a distro only for developers. We are still producing a general purpose OS but we are focusing our own development effort more on making it easier to use Workstation for development.
We had this discussion already when approving the PRD. There were concerns that people might misunderstand the wording there to mean that we are no longer supporting the general desktop user. No; the PRD only enumerates areas we'll give special focus during development and is not meant to say that those are the only supported use cases.
It is still a general purpose desktop distro.
Quoting from the Workstation PRD:
"We want to create a stable, integrated, polished and user friendly system that can appeal to a wide general audience. /.../ This PRD is not meant to be an exhaustive list of what potential users can or will use the Fedora Workstation for, but rather outline the Workstation working groups development priorities and overall goals."
... and goes on to explain that one of those development priorities is to be attractive to developers.
http://fedoraproject.org/wiki/Workstation/Workstation_PRD
On Wed, Jun 4, 2014 at 8:20 AM, Kalev Lember kalevlember@gmail.com wrote:
On 06/04/2014 01:52 PM, Josh Boyer wrote:
I disagree. We aren't targeting people that find virtualization to be a confusing concept. Workstation is targeting developers and students with a reasonable degree of technical competence. I believe working virt out of the box should be installed.
No, sorry, you might have misunderstood the PRD. We aren't producing a distro only for developers. We are still producing a general purpose OS but we are focusing our own development effort more on making it easier to use Workstation for development.
There's nothing in what I said that precludes a general purpose OS. On the contrary, it's required for anything above and beyond that.
We had this discussion already when approving the PRD. There were concerns that people might misunderstand the wording there to mean that we are no longer supporting the general desktop user. No; the PRD only enumerates areas we'll give special focus during development and is not meant to say that those are the only supported use cases.
And this is where you and I differ. I consider virtualization an important enough thing for the areas we're giving special focus to be installed by default. You, apparently, do not. That's a difference of opinion between you and I, not a fundamental misunderstanding of the overall goal on my part.
If you would like, we could certainly put this to a vote in the WG. I may very well be alone in my desire for virt to work out of the box. If we could actually get the WG to vote on it, I'll be happy to shut up either way. I'm interested in making progress, not endless debates.
It is still a general purpose desktop distro.
Again, nothing I've said would imply general functionality doesn't work.
Quoting from the Workstation PRD:
"We want to create a stable, integrated, polished and user friendly system that can appeal to a wide general audience. /.../ This PRD is not meant to be an exhaustive list of what potential users can or will use the Fedora Workstation for, but rather outline the Workstation working groups development priorities and overall goals."
... and goes on to explain that one of those development priorities is to be attractive to developers.
You don't need to point me to the wiki page I created.
josh
On Wed, 2014-06-04 at 16:09 -0400, Josh Boyer wrote:
On Wed, Jun 4, 2014 at 8:20 AM, Kalev Lember kalevlember@gmail.com wrote:
On 06/04/2014 01:52 PM, Josh Boyer wrote:
I disagree. We aren't targeting people that find virtualization to be a confusing concept. Workstation is targeting developers and students with a reasonable degree of technical competence. I believe working virt out of the box should be installed.
No, sorry, you might have misunderstood the PRD. We aren't producing a distro only for developers. We are still producing a general purpose OS but we are focusing our own development effort more on making it easier to use Workstation for development.
There's nothing in what I said that precludes a general purpose OS. On the contrary, it's required for anything above and beyond that.
We had this discussion already when approving the PRD. There were concerns that people might misunderstand the wording there to mean that we are no longer supporting the general desktop user. No; the PRD only enumerates areas we'll give special focus during development and is not meant to say that those are the only supported use cases.
And this is where you and I differ. I consider virtualization an important enough thing for the areas we're giving special focus to be installed by default. You, apparently, do not. That's a difference of opinion between you and I, not a fundamental misunderstanding of the overall goal on my part.
If you would like, we could certainly put this to a vote in the WG. I may very well be alone in my desire for virt to work out of the box. If we could actually get the WG to vote on it, I'll be happy to shut up either way. I'm interested in making progress, not endless debates.
It is still a general purpose desktop distro.
Again, nothing I've said would imply general functionality doesn't work.
Quoting from the Workstation PRD:
"We want to create a stable, integrated, polished and user friendly system that can appeal to a wide general audience. /.../ This PRD is not meant to be an exhaustive list of what potential users can or will use the Fedora Workstation for, but rather outline the Workstation working groups development priorities and overall goals."
... and goes on to explain that one of those development priorities is to be attractive to developers.
You don't need to point me to the wiki page I created.
josh
Gee, you people are polite. I've just migrated from the Lizard, and what goes on there.......i ditched the OS Cheers, Mark
On Wed, Jun 4, 2014 at 4:17 PM, Araluen desertdance2000@optusnet.com.au wrote:
On Wed, 2014-06-04 at 16:09 -0400, Josh Boyer wrote:
On Wed, Jun 4, 2014 at 8:20 AM, Kalev Lember kalevlember@gmail.com wrote:
On 06/04/2014 01:52 PM, Josh Boyer wrote:
I disagree. We aren't targeting people that find virtualization to be a confusing concept. Workstation is targeting developers and students with a reasonable degree of technical competence. I believe working virt out of the box should be installed.
No, sorry, you might have misunderstood the PRD. We aren't producing a distro only for developers. We are still producing a general purpose OS but we are focusing our own development effort more on making it easier to use Workstation for development.
There's nothing in what I said that precludes a general purpose OS. On the contrary, it's required for anything above and beyond that.
We had this discussion already when approving the PRD. There were concerns that people might misunderstand the wording there to mean that we are no longer supporting the general desktop user. No; the PRD only enumerates areas we'll give special focus during development and is not meant to say that those are the only supported use cases.
And this is where you and I differ. I consider virtualization an important enough thing for the areas we're giving special focus to be installed by default. You, apparently, do not. That's a difference of opinion between you and I, not a fundamental misunderstanding of the overall goal on my part.
If you would like, we could certainly put this to a vote in the WG. I may very well be alone in my desire for virt to work out of the box. If we could actually get the WG to vote on it, I'll be happy to shut up either way. I'm interested in making progress, not endless debates.
It is still a general purpose desktop distro.
Again, nothing I've said would imply general functionality doesn't work.
Quoting from the Workstation PRD:
"We want to create a stable, integrated, polished and user friendly system that can appeal to a wide general audience. /.../ This PRD is not meant to be an exhaustive list of what potential users can or will use the Fedora Workstation for, but rather outline the Workstation working groups development priorities and overall goals."
... and goes on to explain that one of those development priorities is to be attractive to developers.
You don't need to point me to the wiki page I created.
josh
Gee, you people are polite. I've just migrated from the Lizard, and what goes on there.......i ditched the OS
I'm not sure if this was sarcastic or not, so I'll be an optimist and assume you were being literal.
Welcome to Fedora, and I hope Workstation, or whichever flavor of Fedora you find suits you best, is a great experience. If you're inclined to pitch in after a while, we'd love the help.
(If my assumption is wrong and you were being sarcastic... well I hope you find Fedora useful anyway.)
josh
On Thu, Jun 05, 2014 at 06:17:46AM +1000, Araluen wrote:
Gee, you people are polite. I've just migrated from the Lizard, and what goes on there.......i ditched the OS
You're also jumping into the middle of a thread on a development list. Context is important. We *do* try to be polite, though. Despite its strengths, the Internet is really a terrible medium for communication and it's easy for communication cues to spiral in the wrong direction.
In any case, cheers, and welcome to Fedora.
On Wed, Jun 04, 2014 at 04:09:14PM -0400, Josh Boyer wrote:
On Wed, Jun 4, 2014 at 8:20 AM, Kalev Lember kalevlember@gmail.com wrote:
On 06/04/2014 01:52 PM, Josh Boyer wrote:
I disagree. We aren't targeting people that find virtualization to be a confusing concept. Workstation is targeting developers and students with a reasonable degree of technical competence. I believe working virt out of the box should be installed.
No, sorry, you might have misunderstood the PRD. We aren't producing a distro only for developers. We are still producing a general purpose OS but we are focusing our own development effort more on making it easier to use Workstation for development.
There's nothing in what I said that precludes a general purpose OS. On the contrary, it's required for anything above and beyond that.
We had this discussion already when approving the PRD. There were concerns that people might misunderstand the wording there to mean that we are no longer supporting the general desktop user. No; the PRD only enumerates areas we'll give special focus during development and is not meant to say that those are the only supported use cases.
And this is where you and I differ. I consider virtualization an important enough thing for the areas we're giving special focus to be installed by default. You, apparently, do not. That's a difference of opinion between you and I, not a fundamental misunderstanding of the overall goal on my part.
If you would like, we could certainly put this to a vote in the WG. I may very well be alone in my desire for virt to work out of the box. If we could actually get the WG to vote on it, I'll be happy to shut up either way. I'm interested in making progress, not endless debates.
It certainly seems like it should be there by default. A common use case I see among developers is testing deployment of code or apps on other platforms. I thought this was one of the motivations behind e.g. GNOME Boxes.
On Thu, 2014-05-29 at 10:20 -0400, Matthias Clasen wrote:
I've attached the full, current package list of the workstation iso (as of yesterday); in case somebody wants to suggests other additions or changes.
I think we either want fortune-mod, or else should patch out the Wanda easter egg in gnome-shell (search for "free the fish" in the overview) if we're really worried about space. It exists, so it should work.
2014-06-25 2:44 GMT+02:00 Michael Catanzaro mcatanzaro@gnome.org:
On Thu, 2014-05-29 at 10:20 -0400, Matthias Clasen wrote:
I've attached the full, current package list of the workstation iso (as of yesterday); in case somebody wants to suggests other additions or changes.
I think we either want fortune-mod, or else should patch out the Wanda easter egg in gnome-shell (search for "free the fish" in the overview) if we're really worried about space. It exists, so it should work.
Wanda was (unfortunately) removed from gnome-shell since October 2013.
Giovanni
On Wed, 2014-06-25 at 11:14 +0200, Giovanni Campagna wrote:
Wanda was (unfortunately) removed from gnome-shell since October 2013.
OK, suggestion retracted!
(Now I'll need to find a new way to decide what to buy for dinner, what funds to invest in, and what doctor to visit. Alas.)
On Wed, Jun 25, 2014 at 08:59:05AM -0500, Michael Catanzaro wrote:
On Wed, 2014-06-25 at 11:14 +0200, Giovanni Campagna wrote:
Wanda was (unfortunately) removed from gnome-shell since October 2013.
OK, suggestion retracted!
I'd say a fortune program belongs into the default install anyway. Anecdotally, I've seen new Unix users read or hear about it and getting confused when the shell just puts a "command not found" message in their face when they try to run it.
The same applies to some other commands which many, many books (plus half the internet) generally describe as "preinstalled on any Unix-like system". As most of those tend to be small anyway, why not just install them by default?
On Tue, Jul 15, 2014 at 1:11 AM, Lars Seipel lars.seipel@gmail.com wrote:
On Wed, Jun 25, 2014 at 08:59:05AM -0500, Michael Catanzaro wrote:
On Wed, 2014-06-25 at 11:14 +0200, Giovanni Campagna wrote:
Wanda was (unfortunately) removed from gnome-shell since October 2013.
OK, suggestion retracted!
I'd say a fortune program belongs into the default install anyway. Anecdotally, I've seen new Unix users read or hear about it and getting confused when the shell just puts a "command not found" message in their face when they try to run it.
The same applies to some other commands which many, many books (plus half the internet) generally describe as "preinstalled on any Unix-like system". As most of those tend to be small anyway, why not just install them by default? -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
It's silly to put fortune in the default install. If people want it they'll type fortune and packagekit-command-not-found will offer to install it.
On Thu, 2014-05-29 at 10:20 -0400, Matthias Clasen wrote:
I'll make sure we add the rest. I've attached the full, current package list of the workstation iso (as of yesterday); in case somebody wants to suggests other additions or changes.
I notice gdb is on the package list, but gcc is not. This combination doesn't seem very useful; what's bringing in gdb?
On Mon, 2014-07-14 at 00:23 +0200, Kalev Lember wrote:
On 07/13/2014 09:08 PM, Michael Catanzaro wrote:
I notice gdb is on the package list, but gcc is not. This combination doesn't seem very useful; what's bringing in gdb?
Abrt I presume.
-- Kalev
OK, good point.
Next question: does ABRT work for you? Everything I've reported in the past month or so ended in an Emergency Analysis (the whole ABRT processing directory gets uploaded to the server, since there was an ABRT bug). Before that, I timed how long it took to report crashes: I believe I clocked a gnote crash at just under 15 minutes, a WebKit crash at about 40. (I'm positive I reported a bug about this, but I can't find it anymore.) This is so far beyond what I personally think is OK that I'd rather Workstation to have no ABRT at all, but I don't know if my experiences are typical. If others are experiencing the same, we should probably discuss where to draw the line and then get in touch with the ABRT devs.
(It's not that I don't want a crash catcher, just that its benefits need to be balanced against the user experience. I think ABRT makes Fedora look bad.)
On 07/14/2014 03:45 PM, Michael Catanzaro wrote:
Next question: does ABRT work for you? Everything I've reported in the past month or so ended in an Emergency Analysis (the whole ABRT processing directory gets uploaded to the server, since there was an ABRT bug). Before that, I timed how long it took to report crashes: I believe I clocked a gnote crash at just under 15 minutes, a WebKit crash at about 40. (I'm positive I reported a bug about this, but I can't find it anymore.) This is so far beyond what I personally think is OK that I'd rather Workstation to have no ABRT at all, but I don't know if my experiences are typical. If others are experiencing the same, we should probably discuss where to draw the line and then get in touch with the ABRT devs.
(It's not that I don't want a crash catcher, just that its benefits need to be balanced against the user experience. I think ABRT makes Fedora look bad.)
My own experience with ABRT is mixed.
As a developer, I absolutely love the retrace server, https://retrace.fedoraproject.org/faf/problems/hot/ . It gives an overview of the most frequent traces ABRT has seen and this is invaluable for prioritizing and fixing crashers that users are experiencing in real world. Also, bug reports filed with ABRT tend to be of high quality, which makes it easy to fix issues reported. I always tell everybody to submit crash reports when ABRT asks them to, since it helps us fix stuff.
As a user, I hate ABRT with all my heart. The UI is confusing to me, it just never seems to work properly (perhaps that's because I run rawhide and ABRT developers don't focus their efforts there), and it also gets in the way of debugging crashes in my own stuff. So I tend to remove it from my systems and file bugs by hand instead, if needed.
On Mon, 2014-07-14 at 16:10 +0200, Kalev Lember wrote:
As a developer, I absolutely love the retrace server, https://retrace.fedoraproject.org/faf/problems/hot/ . It gives an overview of the most frequent traces ABRT has seen and this is invaluable for prioritizing and fixing crashers that users are experiencing in real world. Also, bug reports filed with ABRT tend to be of high quality, which makes it easy to fix issues reported. I always tell everybody to submit crash reports when ABRT asks them to, since it helps us fix stuff.
Yes, this service is wonderful, though lately I've been seeing missing problem reports and wondering if it's working properly.
As a user, I hate ABRT with all my heart. The UI is confusing to me, it just never seems to work properly (perhaps that's because I run rawhide and ABRT developers don't focus their efforts there), and it also gets in the way of debugging crashes in my own stuff. So I tend to remove it from my systems and file bugs by hand instead, if needed.
My experiences are based on F20.
I don't find it gets in the way of debugging my own crashes, though, since by default it creates core dumps in the crashing processes' directory as long as you remember to set ulimit -c. I WILL find it gets in the way of debugging my own crashes in F21, since F21 finally enables systemd's wonderful coredumpctl tool. ABRT is going to conflict with that, but I bet this can be worked on.
I think what you stated (+1 as a developer, -1 as a user) is pretty much how most workstation users feel.
I know for a fact that the ABRT team does work hard, so I don't really wan't to reflect on their efforts, however, if we have the choice in our hands (I don't even know if we do), I think we should probably write down all the negative impact that ABRT has on UX, try to solve it in the mid-run with the ABRT guys, and remove ABRT in the meantime. Because quite frankly, I rather have a nice user experience than crash reports if that's the tradeoff.
So, the question is, do we have the ability to remove it without being in conflict with the other products?
Just my 2 cents.
On Mon, 2014-07-14 at 09:27 -0500, Michael Catanzaro wrote:
On Mon, 2014-07-14 at 16:10 +0200, Kalev Lember wrote:
As a developer, I absolutely love the retrace server, https://retrace.fedoraproject.org/faf/problems/hot/ . It gives an overview of the most frequent traces ABRT has seen and this is invaluable for prioritizing and fixing crashers that users are experiencing in real world. Also, bug reports filed with ABRT tend to be of high quality, which makes it easy to fix issues reported. I always tell everybody to submit crash reports when ABRT asks them to, since it helps us fix stuff.
Yes, this service is wonderful, though lately I've been seeing missing problem reports and wondering if it's working properly.
As a user, I hate ABRT with all my heart. The UI is confusing to me, it just never seems to work properly (perhaps that's because I run rawhide and ABRT developers don't focus their efforts there), and it also gets in the way of debugging crashes in my own stuff. So I tend to remove it from my systems and file bugs by hand instead, if needed.
My experiences are based on F20.
I don't find it gets in the way of debugging my own crashes, though, since by default it creates core dumps in the crashing processes' directory as long as you remember to set ulimit -c. I WILL find it gets in the way of debugging my own crashes in F21, since F21 finally enables systemd's wonderful coredumpctl tool. ABRT is going to conflict with that, but I bet this can be worked on. -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
It is +1 for user also.
It makes it easy to open a new Bugzilla ticket.
Its a real pain to file a new bug and very time consuming when you have to do it manually. (or just me being lazy)
ABRT and Setroubleshoot are the main reasons I am still using Fedora.
On Mon, Jul 14, 2014 at 7:38 AM, Alberto Ruiz aruiz@redhat.com wrote:
I think what you stated (+1 as a developer, -1 as a user) is pretty much how most workstation users feel.
I know for a fact that the ABRT team does work hard, so I don't really wan't to reflect on their efforts, however, if we have the choice in our hands (I don't even know if we do), I think we should probably write down all the negative impact that ABRT has on UX, try to solve it in the mid-run with the ABRT guys, and remove ABRT in the meantime. Because quite frankly, I rather have a nice user experience than crash reports if that's the tradeoff.
So, the question is, do we have the ability to remove it without being in conflict with the other products?
Just my 2 cents.
On Mon, 2014-07-14 at 09:27 -0500, Michael Catanzaro wrote:
On Mon, 2014-07-14 at 16:10 +0200, Kalev Lember wrote:
As a developer, I absolutely love the retrace server, https://retrace.fedoraproject.org/faf/problems/hot/ . It gives an overview of the most frequent traces ABRT has seen and this is invaluable for prioritizing and fixing crashers that users are experiencing in real world. Also, bug reports filed with ABRT tend to be of high quality, which makes it easy to fix issues reported. I always tell everybody to submit crash reports when ABRT asks them to, since it helps us fix stuff.
Yes, this service is wonderful, though lately I've been seeing missing problem reports and wondering if it's working properly.
As a user, I hate ABRT with all my heart. The UI is confusing to me, it just never seems to work properly (perhaps that's because I run rawhide and ABRT developers don't focus their efforts there), and it also gets in the way of debugging crashes in my own stuff. So I tend to remove it from my systems and file bugs by hand instead, if needed.
My experiences are based on F20.
I don't find it gets in the way of debugging my own crashes, though, since by default it creates core dumps in the crashing processes' directory as long as you remember to set ulimit -c. I WILL find it gets in the way of debugging my own crashes in F21, since F21 finally enables systemd's wonderful coredumpctl tool. ABRT is going to conflict with that, but I bet this can be worked on. -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
-- Greetings, Alberto Ruiz Engineering Manager - Desktop Applications Team Red Hat, Inc.
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
----- Original Message -----
From: "Alberto Ruiz" aruiz@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Monday, July 14, 2014 4:38:24 PM Subject: Re: ABRT?
I think what you stated (+1 as a developer, -1 as a user) is pretty much how most workstation users feel.
I know for a fact that the ABRT team does work hard, so I don't really wan't to reflect on their efforts, however, if we have the choice in our hands (I don't even know if we do), I think we should probably write down all the negative impact that ABRT has on UX, try to solve it in the mid-run with the ABRT guys, and remove ABRT in the meantime. Because quite frankly, I rather have a nice user experience than crash reports if that's the tradeoff.
Well as annoying abrt can be I think nothing ruins the user experience more than crashers, so if abrt helps us fix more crashers/the most important crashers, I think that improvement in user experience probably outweighs the irritation of abrt.
Christian
So, the question is, do we have the ability to remove it without being in conflict with the other products?
Just my 2 cents.
On Mon, 2014-07-14 at 09:27 -0500, Michael Catanzaro wrote:
On Mon, 2014-07-14 at 16:10 +0200, Kalev Lember wrote:
As a developer, I absolutely love the retrace server, https://retrace.fedoraproject.org/faf/problems/hot/ . It gives an overview of the most frequent traces ABRT has seen and this is invaluable for prioritizing and fixing crashers that users are experiencing in real world. Also, bug reports filed with ABRT tend to be of high quality, which makes it easy to fix issues reported. I always tell everybody to submit crash reports when ABRT asks them to, since it helps us fix stuff.
Yes, this service is wonderful, though lately I've been seeing missing problem reports and wondering if it's working properly.
As a user, I hate ABRT with all my heart. The UI is confusing to me, it just never seems to work properly (perhaps that's because I run rawhide and ABRT developers don't focus their efforts there), and it also gets in the way of debugging crashes in my own stuff. So I tend to remove it from my systems and file bugs by hand instead, if needed.
My experiences are based on F20.
I don't find it gets in the way of debugging my own crashes, though, since by default it creates core dumps in the crashing processes' directory as long as you remember to set ulimit -c. I WILL find it gets in the way of debugging my own crashes in F21, since F21 finally enables systemd's wonderful coredumpctl tool. ABRT is going to conflict with that, but I bet this can be worked on. -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
-- Greetings, Alberto Ruiz Engineering Manager - Desktop Applications Team Red Hat, Inc.
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
I see your point,
However I would subject it to our capacity to respond to ABRT crasher, do we have a measure as to how much quality do we bring thanks to ABRT vs a measure of how often and how badly ABRT impacts the experience?
I will give you an example, I have had a couple of crashers that brought ABRT to consume all my machine resources, rendering it unusable. The crasher itself is bad, but freezing the whole system because an app decided to crash is even worse than the crash.
From my POV it all boils down to figuring out if the ABRT guys are aware
about these issues and if they plan to fix them anytime soon.
On Mon, 2014-07-14 at 11:38 -0400, Christian Schaller wrote:
----- Original Message -----
From: "Alberto Ruiz" aruiz@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Monday, July 14, 2014 4:38:24 PM Subject: Re: ABRT?
I think what you stated (+1 as a developer, -1 as a user) is pretty much how most workstation users feel.
I know for a fact that the ABRT team does work hard, so I don't really wan't to reflect on their efforts, however, if we have the choice in our hands (I don't even know if we do), I think we should probably write down all the negative impact that ABRT has on UX, try to solve it in the mid-run with the ABRT guys, and remove ABRT in the meantime. Because quite frankly, I rather have a nice user experience than crash reports if that's the tradeoff.
Well as annoying abrt can be I think nothing ruins the user experience more than crashers, so if abrt helps us fix more crashers/the most important crashers, I think that improvement in user experience probably outweighs the irritation of abrt.
Christian
So, the question is, do we have the ability to remove it without being in conflict with the other products?
Just my 2 cents.
On Mon, 2014-07-14 at 09:27 -0500, Michael Catanzaro wrote:
On Mon, 2014-07-14 at 16:10 +0200, Kalev Lember wrote:
As a developer, I absolutely love the retrace server, https://retrace.fedoraproject.org/faf/problems/hot/ . It gives an overview of the most frequent traces ABRT has seen and this is invaluable for prioritizing and fixing crashers that users are experiencing in real world. Also, bug reports filed with ABRT tend to be of high quality, which makes it easy to fix issues reported. I always tell everybody to submit crash reports when ABRT asks them to, since it helps us fix stuff.
Yes, this service is wonderful, though lately I've been seeing missing problem reports and wondering if it's working properly.
As a user, I hate ABRT with all my heart. The UI is confusing to me, it just never seems to work properly (perhaps that's because I run rawhide and ABRT developers don't focus their efforts there), and it also gets in the way of debugging crashes in my own stuff. So I tend to remove it from my systems and file bugs by hand instead, if needed.
My experiences are based on F20.
I don't find it gets in the way of debugging my own crashes, though, since by default it creates core dumps in the crashing processes' directory as long as you remember to set ulimit -c. I WILL find it gets in the way of debugging my own crashes in F21, since F21 finally enables systemd's wonderful coredumpctl tool. ABRT is going to conflict with that, but I bet this can be worked on. -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
-- Greetings, Alberto Ruiz Engineering Manager - Desktop Applications Team Red Hat, Inc.
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Mon, 2014-07-14 at 11:38 -0400, Christian Schaller wrote:
Well as annoying abrt can be I think nothing ruins the user experience more than crashers, so if abrt helps us fix more crashers/the most important crashers, I think that improvement in user experience probably outweighs the irritation of abrt.
Christian
I think it is a thing we really want to have, since it helps find crashes and that's very important, but it's just not ready for general users. Even if you're OK with the extremely long waits, they usually end in an emergency report, and before the emergency reports started they would usually end with a notice that the crash cannot be reported. I'm actually confused how users are managing to report any bugs at all -- it just *doesn't work* at least for me. I'm not objecting to the theory behind ABRT, just the current implementation. If it gets dropped, I would happily welcome it back once these issues are resolved.
P.S. If memory serves, and it might not, I think ABRT may have been faster and much more reliable in the past. I don't remember being annoyed with it when I started using Fedora (F18 era).
Michael Catanzaro píše v Po 14. 07. 2014 v 11:02 -0500:
On Mon, 2014-07-14 at 11:38 -0400, Christian Schaller wrote:
Well as annoying abrt can be I think nothing ruins the user experience more than crashers, so if abrt helps us fix more crashers/the most important crashers, I think that improvement in user experience probably outweighs the irritation of abrt.
Christian
I think it is a thing we really want to have, since it helps find crashes and that's very important, but it's just not ready for general users. Even if you're OK with the extremely long waits, they usually end in an emergency report, and before the emergency reports started they would usually end with a notice that the crash cannot be reported. I'm actually confused how users are managing to report any bugs at all -- it just *doesn't work* at least for me. I'm not objecting to the theory behind ABRT, just the current implementation. If it gets dropped, I would happily welcome it back once these issues are resolved.
P.S. If memory serves, and it might not, I think ABRT may have been faster and much more reliable in the past. I don't remember being annoyed with it when I started using Fedora (F18 era).
I think it's important to distinguish two things ABRT does:
1. it makes (or at least it is supposed to) it easier to report bugs to bugzilla.
2. it makes so called ureports that are used for the statistics and weighting problems.
ad 1) I think ABRT offers two ways to create backtraces etc. Either on their server or on your machine. AFAIK ABRT started preferring the former option because users don't have to install all the debug tools to report a problem, but if their server is overloaded it may take ages to create a bug report.
ad 2) This is not slow at all. ureports are created and uploaded within seconds.
I agree with Christian. We should not remove ABRT completely. The retrace server is an important tool for many developers. If reporting bugs is broken, then we may disable it and let ABRT create only the ureports until it's fixed. On the other hand, we would lose links to actual bug reports in bugzilla. I also agree that there needs to be something done with the UI which is frankly quite terrible.
Jiri
On Wed, Jul 16, 2014 at 11:59 AM, Jiri Eischmann eischmann@redhat.com wrote:
I think it's important to distinguish two things ABRT does:
- it makes (or at least it is supposed to) it easier to report bugs to
bugzilla.
Lately ABRT is very slow to report bugs even if you ignore the UI
problems. I've had reports fail with an unexplained error, and I had issues where ABRT simply deleted the problem directory when I was in the middle of writing a description. It clearly doesn't work as well as it should
- it makes so called ureports that are used for the statistics and
weighting problems.
ad 1) I think ABRT offers two ways to create backtraces etc. Either on their server or on your machine. AFAIK ABRT started preferring the former option because users don't have to install all the debug tools to report a problem, but if their server is overloaded it may take ages to create a bug report.
Some users have extremely slow upload speeds, so uploading a 100MB core dump takes ages. Downloading the debuginfo is also a problem for people with slow download speed.
Fedora executables and shared objects are compiled with a minimized form of debuginfo. It allows creating a simple backtrace even when you don't have the huge -debuginfo packages installed, when the only downside for this case is that you'll not have source line names, only symbol names and the name of the shared object they came from.
I think that if we want to improve ABRT's UX, we need to get rid of the retrace server AND the debuginfo downloading, an generate the backtrace for the bugreport without these. The backtrace will take less than a minute to generate (in most cases) and is better than nothing. Users won't have to wait HOURS for the debuginfo to download or the coredump to upload just to be informed the reporting "failed".
ad 2) This is not slow at all. ureports are created and uploaded within seconds.
I agree with Christian. We should not remove ABRT completely. The retrace server is an important tool for many developers. If reporting bugs is broken, then we may disable it and let ABRT create only the ureports until it's fixed. On the other hand, we would lose links to actual bug reports in bugzilla. I also agree that there needs to be something done with the UI which is frankly quite terrible.
Until ABRT's UX and UI improve, I think including it in the default install makes no sense. From my experience with ABRT it's usually easier to open a bugzilla bug manually than going through the long, slow, annoying process of ABRT reports. I'm honestly surprised we get many ABRT bug reports because the process is simply too annoying to expect any regular user to actually complete it.
Also, I think the amount of useless ABRT crash reports, or crash reports ignored by packagers is much higher than the reports that are actually looked into and fixed. And it makes sense, because packagers are usually not developers and wouldn't know what to do with most of the crashes, and moving countless of crash reports upstream is simply too much boring work for packagers to do. Like said elsewhere in this thread, ABRT should have the option for packagers to define which bug tracker to use for crashes. GNOME crashes should be reported the the GNOME bugzilla, KDE crashes should be reported to the KDE bugtracker, etc etc.
I think we need to remove ABRT by default in F21, or limit it to sending ureports without any UI or notification, and work to make the UI and UX better so we can reconsider ABRT's inclusion in F22. Ideally, the process should take less than 5 minutes for most bugs (and the number of steps in the "wizard" should be greatly reduced), and the notifications should be made less annoying (see the designs in the GNOME wiki).
On Wed, 2014-07-16 at 12:22 +0300, Elad Alfassa wrote:
I think we need to remove ABRT by default in F21, or limit it to sending ureports without any UI or notification, and work to make the UI and UX better so we can reconsider ABRT's inclusion in F22. Ideally, the process should take less than 5 minutes for most bugs (and the number of steps in the "wizard" should be greatly reduced), and the notifications should be made less annoying (see the designs in the GNOME wiki).
Maybe the notifications are a good thing, since they clarify to the user what has happened. Otherwise he's going to be confused if his program just disappears.
Hi,
On Wed, Jul 16, 2014 at 12:22:51PM +0300, Elad Alfassa wrote:
On Wed, Jul 16, 2014 at 11:59 AM, Jiri Eischmann eischmann@redhat.com wrote:
ad 1) I think ABRT offers two ways to create backtraces etc. Either on their server or on your machine. AFAIK ABRT started preferring the former option because users don't have to install all the debug tools to report a problem, but if their server is overloaded it may take ages to create a bug report.
Some users have extremely slow upload speeds, so uploading a 100MB core dump takes ages. Downloading the debuginfo is also a problem for people with slow download speed.
So maybe these users might prefer not to use abrt? There are also users with very high upload/download speeds, for whom neither is a problem...
Fedora executables and shared objects are compiled with a minimized form of debuginfo. It allows creating a simple backtrace even when you don't have the huge -debuginfo packages installed, when the only downside for this case is that you'll not have source line names, only symbol names and the name of the shared object they came from.
I think that if we want to improve ABRT's UX, we need to get rid of the retrace server AND the debuginfo downloading, an generate the backtrace for the bugreport without these.
Yeah, why not. Because it is already hard to get an idea about the reason for the crash from the backtrace, let's make it even harder! </sarcasm>
Frankly, rather than that, it would be much better to disable abrt bug reporting completely.
The backtrace will take less than a minute to generate (in most cases) and is better than nothing.
No, it is not. From packager's POV it is worse than nothing, as it forces me to spend time on the bug, even though the expectation of successuful identification of the problem is practically zero.
D.
On Thu, Jul 17, 2014 at 10:52 AM, David Tardon dtardon@redhat.com wrote:
Hi,
On Wed, Jul 16, 2014 at 12:22:51PM +0300, Elad Alfassa wrote:
On Wed, Jul 16, 2014 at 11:59 AM, Jiri Eischmann eischmann@redhat.com wrote:
ad 1) I think ABRT offers two ways to create backtraces etc. Either on their server or on your machine. AFAIK ABRT started preferring the former option because users don't have to install all the debug tools
to
report a problem, but if their server is overloaded it may take ages to create a bug report.
Some users have extremely slow upload speeds, so uploading a 100MB core dump takes ages. Downloading the debuginfo is also a problem for people with slow download speed.
So maybe these users might prefer not to use abrt? There are also users with very high upload/download speeds, for whom neither is a problem...
So if a user has a slow connection and they get this notification, you
want them to spend hours only to understand "oh maybe my computer is too slow for this" and give up? That's an horrible user experience and it makes our product look bad. If you build a product that works well on slow connections, it will work well on fast connections too. However, if you build a product that only works well on fiber-to-home connections, millions of people around the world will find your product unusable. Many people use slow mobile connections (EDGE, 3G), ADSL, or even dial up, and you can't just ignore these people when designing the UX of your product.
Fedora executables and shared objects are compiled with a minimized form
of
debuginfo. It allows creating a simple backtrace even when you don't have the huge -debuginfo packages installed, when the only downside for this case is that you'll not have source line names, only symbol names and the name of the shared object they came from.
I think that if we want to improve ABRT's UX, we need to get rid of the retrace server AND the debuginfo downloading, an generate the backtrace
for
the bugreport without these.
Yeah, why not. Because it is already hard to get an idea about the reason for the crash from the backtrace, let's make it even harder!
</sarcasm>
Frankly, rather than that, it would be much better to disable abrt bug reporting completely.
The backtrace will take less than a minute to generate (in most cases)
and
is better than nothing.
No, it is not. From packager's POV it is worse than nothing, as it forces me to spend time on the bug, even though the expectation of successuful identification of the problem is practically zero.
You can debug crashes successfully even with such limited backtrace. Making a random packager's life a little easier is not worth making our product look bad. If you really need further details from a crash, you can always ask the user to provide them.
Hi,
On Thu, Jul 17, 2014 at 11:10:39AM +0300, Elad Alfassa wrote:
On Thu, Jul 17, 2014 at 10:52 AM, David Tardon dtardon@redhat.com wrote:
The backtrace will take less than a minute to generate (in most cases)
and
is better than nothing.
No, it is not. From packager's POV it is worse than nothing, as it forces me to spend time on the bug, even though the expectation of successuful identification of the problem is practically zero.
You can debug crashes successfully even with such limited backtrace.
My experience with libreoffice bugs is very different.
Making a random packager's life a little easier is not worth making our product look bad.
Well, packagers can be viewed as users of of the abrt bug reports. So, to paraphrase your words: if you create reports that work for maintainers of big applications with hundreds of thousands of lines of code, it will work well for maintainers of small applications too. However, if you create reports that only work well for maintainers of small applications with a few thousands of lines of code, which those maintainers know from top to bottom because they wrote it, many other maintainers will find your reports unusable.
If you really need further details from a crash, you can always ask the user to provide them.
Sure. Except that 80% of them will not answer and 80% of the rest will only say that they cannot add anything because they do not remember how the crash happened.
D.
On Thu, 2014-07-17 at 14:21 +0200, David Tardon wrote:
My experience with libreoffice bugs is very different.
I would imagine that LO bugs are more difficult than typical, since LO is of a scale incomparable to our other applications.
A partial backtrace is often enough to debug many issues. It's definitely not as useful as a full one.
Making a random packager's life a little easier is not worth making our
product
look bad.
Well, packagers can be viewed as users of of the abrt bug reports. So, to paraphrase your words: if you create reports that work for maintainers of big applications with hundreds of thousands of lines of code, it will work well for maintainers of small applications too. However, if you create reports that only work well for maintainers of small applications with a few thousands of lines of code, which those maintainers know from top to bottom because they wrote it, many other maintainers will find your reports unusable.
If you really need further details from a crash, you can always ask the user to provide them.
Sure. Except that 80% of them will not answer and 80% of the rest will only say that they cannot add anything because they do not remember how the crash happened.
All of your points are valid. There's a trade-off here. I think the decision is very clear for just one reason: 90% of the time when I try to report a bug, ABRT works for 15-40 minutes then says the problem is unreportable. Subjecting users to that by default is not OK, even if it means the other 10% of quality bug reports don't come in.
On 07/17/2014 03:10 PM, Michael Catanzaro wrote:
All of your points are valid. There's a trade-off here. I think the decision is very clear for just one reason: 90% of the time when I try to report a bug, ABRT works for 15-40 minutes then says the problem is unreportable. Subjecting users to that by default is not OK, even if it means the other 10% of quality bug reports don't come in.
It's not very clear as what you describe is the worst case scenario that shouldn't happen often.
I agree that reporting process [1] is quite clumsy (and there are reasons for that) but most users won't even get to the point of the retracing process as their ureport is often matched with previous reports and all they get is fast response from faf which contains link to faf's report and link to bugzilla. This happens right after you click Report and you're only subjected to the rest of the reporting torture only in a case that your crash is unique.
As Jirka pointed out, retrace server is often overloaded to the point that retracing of small coredump takes very long time. The machine where it's hosted is also being upgraded so this shouldn't be an issue when the upgrade is in place.
The real problem are the executables that generate unreportable backtraces [2] as this leads to disappointment at the end of the retracing process and this is what we are actually trying to resolve so please file a bugzilla when this happens (ideally with a coredump attached).
The point, if it's ok to subject users to reporting was raised before and addressed by our team by the configuration option called Shortened reporting:
Enables shortened GUI reporting where the reporting is interrupted after AutoreportingEvent is done. Default value: Yes but only if application is running in GNOME desktop
So users who have enabled autoreporting [3] (ABRT asks for the first time) are not subjected to the reporting process until they specifically hit Report in gnome-abrt application.
Would it be better if we add a warning there that the reporting process is only for advanced users and requires Bugzilla credentials?
Our plan was to have this configured during the installation process so users can configure ABRT to their liking but this is not in place yet.
[1] http://abrt.readthedocs.org/en/latest/howitworks.html [2] http://abrt.readthedocs.org/en/latest/faq.html#why-is-my-backtrace-unusable [3] http://abrt.readthedocs.org/en/latest/conf.html?highlight=short#desktop-sess...
Cheers, Richard Marko
Hey Richard,
On Wed, 2014-07-23 at 16:15 +0200, Richard Marko wrote:
It's not very clear as what you describe is the worst case scenario that shouldn't happen often.
I agree that reporting process [1] is quite clumsy (and there are reasons for that) but most users won't even get to the point of the retracing process as their ureport is often matched with previous reports and all they get is fast response from faf which contains link to faf's report and link to bugzilla. This happens right after you click Report and you're only subjected to the rest of the reporting torture only in a case that your crash is unique.
In practice my experience has been that ABRT is rarely able to automatically match my crash with an existing Bugzilla report, so that the user doesn't need to go through the Bugzilla report process if he wants to make sure the bug makes it to Bugzilla. This is wonderful when it does work, though.
The clumsy reporting process is something that should be improved, but I don't think it's a super serious problem that should preclude the inclusion of gnome-abrt in Fedora Workstation. I think the two remaining serious problems are speed and unusable backtraces.
As Jirka pointed out, retrace server is often overloaded to the point that retracing of small coredump takes very long time. The machine
where
it's hosted is also being upgraded so this shouldn't be an issue when the upgrade is in place.
OK, that's wonderful news. Do you have any estimate on when the upgrade will occur? Is it possible that a cluster of servers may be needed to spread the workload?
The real problem are the executables that generate unreportable backtraces [2] as this leads to disappointment at the end of the retracing process and this is what we are actually trying to resolve so please file a bugzilla when this happens (ideally with a coredump attached).
Unfortunately this is still the most common outcome for me, so much so that I've usually stopped trying to report crashes to Bugzilla. I've filed a couple Bugzilla tickets for this in the past, [1] and [2].
I, personally, think the unreportable backtrace and the speed problems should be the only remaining blockers here.
So users who have enabled autoreporting [3] (ABRT asks for the first time) are not subjected to the reporting process until they specifically hit Report in gnome-abrt application.
Yes, I think this is already a good default.
Would it be better if we add a warning there that the reporting process is only for advanced users and requires Bugzilla credentials?
I don't think the reporting process is so complicated that we need to restrict it to advanced users only. (If that were the case, I would question whether we want to install an app by default that exists only for use by advanced users.) The speed and reliability issues are problems for both advanced users and nontechnical users.
There should indeed be a friendly dialog to help you configure your Red Hat Bugzilla credentials on first use, though. I seem to recall that ABRT does not currently handle a lack of Bugzilla credentials very gracefully.
Thanks and Happy Wednesday,
Michael
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1047556 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1055627
On Wed, 2014-07-23 at 16:15 +0200, Richard Marko wrote:
So users who have enabled autoreporting [3] (ABRT asks for the first time) are not subjected to the reporting process until they specifically hit Report in gnome-abrt application.
Would it be better if we add a warning there that the reporting process is only for advanced users and requires Bugzilla credentials?
Our plan was to have this configured during the installation process so users can configure ABRT to their liking but this is not in place yet.
https://wiki.gnome.org/Design/OS/ProblemReporting#Tentative_Design
does a good job of describing the different levels of detail and interactivity that might be desirable for problem reporting.
The overlap with a developer-focused workstation might be interesting - if you are developing software on the system, you probably don't want to get a crash collection system to get between your crashing app and the debugger.
But if you are an OS developer / packager, you may find it convenient to set up your account details once, and have crashes be collected/reported automatically without asking you every time.
The managed/unattended use cases may not be that important for the workstation product per se, but are still important to keep in mind.
On 23/07/14 19:38, Matthias Clasen wrote:
https://wiki.gnome.org/Design/OS/ProblemReporting#Tentative_Design
does a good job of describing the different levels of detail and interactivity that might be desirable for problem reporting.
The overlap with a developer-focused workstation might be interesting - if you are developing software on the system, you probably don't want to get a crash collection system to get between your crashing app and the debugger.
that's a good point, and it looks like this already works in current Fedora releases - here /proc/sys/kernel/core_pattern calls /usr/libexec/abrt-hook-ccpp but it's apparently smart enough to handle applications that aren't in /usr in the "traditional" way and writes a core.pid file (if enabled with ulimit); so things like LibreOffice's build system automatically running gdb to get a backtrace when a unit test crashes work fine.
On Thu, 2014-07-24 at 12:36 +0200, Michael Stahl wrote:
that's a good point, and it looks like this already works in current Fedora releases - here /proc/sys/kernel/core_pattern calls /usr/libexec/abrt-hook-ccpp but it's apparently smart enough to handle applications that aren't in /usr in the "traditional" way and writes a core.pid file (if enabled with ulimit); so things like LibreOffice's build system automatically running gdb to get a backtrace when a unit test crashes work fine.
Yes, this already works great by default.
It would be very nice if the core dump went to coredumpctl instead of the process's cwd, but this is just a matter of preference.
On Wed, 2014-07-23 at 16:15 +0200, Richard Marko wrote:
As Jirka pointed out, retrace server is often overloaded to the point that retracing of small coredump takes very long time. The machine where it's hosted is also being upgraded so this shouldn't be an issue when the upgrade is in place.
Hey Richard and Workstation WG,
Reporting to Bugzilla is still extremely slow (I gave up on a report today after roughly 10 minutes of "preparing environment for backtrace generation). Unless this retrace server upgrade is coming very soon and is expected to produce an order of magnitude performance increase, then I think we should go ahead and disable reporting to Bugzilla in the meantime. We can do this by removing the gnome-abrt package while leaving the other abrt packages in place. Try this locally to see how it works -- ABRT will still process the crashes and send automatic crash reports to the retrace server, unobtrusively notifying the user when it has done so, but the problematic UI for reporting to Bugzilla will be gone.
There is one minor bug: once, by clicking on the notification in some particular way, I received a notification that said "Failed to launch abrt.desktop" (or something similar). It disappeared pretty quickly and I haven't managed to reproduce. Besides that problem, this seems like a good option to consider as the default for Workstation.
Michael
Hello,
I am working on a new version of ABRT which should have Bugzilla disabled in GNOME by default. So, it won't be necessary to remove any package, everything will be done on ABRT side. Unfortunately, I cannot release the updated packages until we upgrade the Fedora's ABRT server. And I would rather hear some feedback before I push those changes to upstream.
See: https://github.com/abrt/abrt/wiki/GUI-Shortened-Reporting
Regards, Jakub
----- Original Message ----- From: "Michael Catanzaro" mcatanzaro@gnome.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Sunday, August 10, 2014 7:27:24 PM Subject: Re: ABRT?
On Wed, 2014-07-23 at 16:15 +0200, Richard Marko wrote:
As Jirka pointed out, retrace server is often overloaded to the point that retracing of small coredump takes very long time. The machine where it's hosted is also being upgraded so this shouldn't be an issue when the upgrade is in place.
Hey Richard and Workstation WG,
Reporting to Bugzilla is still extremely slow (I gave up on a report today after roughly 10 minutes of "preparing environment for backtrace generation). Unless this retrace server upgrade is coming very soon and is expected to produce an order of magnitude performance increase, then I think we should go ahead and disable reporting to Bugzilla in the meantime. We can do this by removing the gnome-abrt package while leaving the other abrt packages in place. Try this locally to see how it works -- ABRT will still process the crashes and send automatic crash reports to the retrace server, unobtrusively notifying the user when it has done so, but the problematic UI for reporting to Bugzilla will be gone.
There is one minor bug: once, by clicking on the notification in some particular way, I received a notification that said "Failed to launch abrt.desktop" (or something similar). It disappeared pretty quickly and I haven't managed to reproduce. Besides that problem, this seems like a good option to consider as the default for Workstation.
Michael
Hello Jakub,
----- Original Message -----
Hello,
I am working on a new version of ABRT which should have Bugzilla disabled in GNOME by default. So, it won't be necessary to remove any package, everything will be done on ABRT side. Unfortunately, I cannot release the updated packages until we upgrade the Fedora's ABRT server. And I would rather hear some feedback before I push those changes to upstream.
See: https://github.com/abrt/abrt/wiki/GUI-Shortened-Reporting
Could you please explain what the differences are in the workflow? One of the problems of having to input comments before the report is done is still there, and users still need to wait in front of the dialogue when reporting bugs against the ABRT server.
I also note that the core dump uploading, which gdb engineers advised against, is still there for all the reports sent to the ABRT server. I think that ABRT should be able to setup a fuse-like share to gather the debuginfo from, without having to upload a potentially huge core file. That also means that the process of unpacking/preparing the packages for gdb can be started much earlier (before the core dump would have reached the server in the old case).
Finally, I'd still prefer a way for the stack traces with mini-debug that should already be available on the system to be uploaded without interaction. Full debug traces could be sent out as additional information to those reports (whether they end up in Bugzilla or just on the ABRT server).
Cheers
Dear Bastien,
Thank you for the quick response!
On Mon, 2014-08-11 at 05:20 -0400, Bastien Nocera wrote:
Hello Jakub,
----- Original Message -----
Hello,
I am working on a new version of ABRT which should have Bugzilla disabled in GNOME by default. So, it won't be necessary to remove any package, everything will be done on ABRT side. Unfortunately, I cannot release the updated packages until we upgrade the Fedora's ABRT server. And I would rather hear some feedback before I push those changes to upstream.
See: https://github.com/abrt/abrt/wiki/GUI-Shortened-Reporting
Could you please explain what the differences are in the workflow?
My intention was to describe the new workflow on the page I sent in the first email:
https://github.com/abrt/abrt/wiki/GUI-Shortened-Reporting
Can you see the differences between "Shortened Reporting ON" (the new workflow) and "Shortened Reporting OFF" (the old workflow)?
One of the problems of having to input comments before the report is done is still there, and users still need to wait in front of the dialogue when reporting bugs against the ABRT server.
If you click "Report" in the notification bubble, no input is required and the reporting finishes immediately.
If you click "Report" in the GUI, the reporting window allows you to provide a description, informs you about processing and tells you that the reporting is done. The workflow is almost the same as the workflow for New Report in Normal mode at: https://wiki.gnome.org/Design/Apps/Oops
I guess the problem is that the reporting window isn't closed right after the click on "Send" button. I will try to fix it.
I also note that the core dump uploading, which gdb engineers advised against,
Pardon? I am not sure I understand you. Where gdb engineers advised such a thing?
is still there for all the reports sent to the ABRT server.
No, the new workflow doesn't upload the core dump. If ABRT uploads the core dump, it is a bug or you don't have Shortened Reporting ON:
https://github.com/abrt/abrt/wiki/Configuration#shortened-reporting
I think that ABRT should be able to setup a fuse-like share to gather the debuginfo from, without having to upload a potentially huge core file. That also means that the process of unpacking/preparing the packages for gdb can be started much earlier (before the core dump would have reached the server in the old case).
Please, excuse my ignorance, but what is fuse-like share? How should it work together with ABRT?
Finally, I'd still prefer a way for the stack traces with mini-debug that should already be available on the system to be uploaded without interaction. Full debug traces could be sent out as additional information to those reports (whether they end up in Bugzilla or just on the ABRT server).
Yes, if you use the notification bubbles for reporting, then ABRT works as you describe. You can also enable the Auto-reporting to get rid of necessity to click "Report" button in the notification bubble:
https://github.com/abrt/abrt/wiki/Configuration#autoreporting
The new workflow disables Bugzilla (and all the tings before opening a new Bugzilla bug) when Shortened Reporting is ON for the reporting process started from the GUI.
Cheers
Sincerely yours, Jakub
----- Original Message -----
Dear Bastien,
Thank you for the quick response!
On Mon, 2014-08-11 at 05:20 -0400, Bastien Nocera wrote:
Hello Jakub,
----- Original Message -----
Hello,
I am working on a new version of ABRT which should have Bugzilla disabled in GNOME by default. So, it won't be necessary to remove any package, everything will be done on ABRT side. Unfortunately, I cannot release the updated packages until we upgrade the Fedora's ABRT server. And I would rather hear some feedback before I push those changes to upstream.
See: https://github.com/abrt/abrt/wiki/GUI-Shortened-Reporting
Could you please explain what the differences are in the workflow?
My intention was to describe the new workflow on the page I sent in the first email:
https://github.com/abrt/abrt/wiki/GUI-Shortened-Reporting
Can you see the differences between "Shortened Reporting ON" (the new workflow) and "Shortened Reporting OFF" (the old workflow)?
I can see the difference, but I don't understand why I can't comment again after the first time I've commented. The process to skip commenting the first time is also sub-par. Given that the window is only there to show progress, maybe it doesn't need to be there at all, and progress can be shown in the main window.
Are you after a UI review after that?
One of the problems of having to input comments before the report is done is still there, and users still need to wait in front of the dialogue when reporting bugs against the ABRT server.
If you click "Report" in the notification bubble, no input is required and the reporting finishes immediately.
Why is the work-flow different in this case? Why would the user want *not* to report the bug? Either do it automatically, or simply cache it all so that they can be reported by hand later, in the UI.
If you click "Report" in the GUI, the reporting window allows you to provide a description, informs you about processing and tells you that the reporting is done. The workflow is almost the same as the workflow for New Report in Normal mode at: https://wiki.gnome.org/Design/Apps/Oops
I don't see any windows besides the main window in those mockups. The "add comment" variant is only there for developers.
I guess the problem is that the reporting window isn't closed right after the click on "Send" button. I will try to fix it.
You could start reporting the backtrace straight away when clicking report, and appending a comment after that if the user deemed it necessary to do so.
I also note that the core dump uploading, which gdb engineers advised against,
Pardon? I am not sure I understand you. Where gdb engineers advised such a thing?
The gdb engineers, as well as security engineers, I talked to thought it was a bad thing for the core dump to even travel to a remote machine. The remote gdb could be vulnerable to a carefully crafted core dump, potentially gaining access to the server, and also other user's core dumps.
Even if the core dump generation using gdb on the remote server is secure, other services that it offers could be compromised and attackers could harvest passwords and other data from the core dumps.
is still there for all the reports sent to the ABRT server.
No, the new workflow doesn't upload the core dump. If ABRT uploads the core dump, it is a bug or you don't have Shortened Reporting ON:
https://github.com/abrt/abrt/wiki/Configuration#shortened-reporting
Right, but that's still available when doing "shortened reporting off", no? I don't understand how one would switch between those 2 modes, or how they might know the difference.
I think that ABRT should be able to setup a fuse-like share to gather the debuginfo from, without having to upload a potentially huge core file. That also means that the process of unpacking/preparing the packages for gdb can be started much earlier (before the core dump would have reached the server in the old case).
Please, excuse my ignorance, but what is fuse-like share? How should it work together with ABRT?
User-space filesystem. You'd have a remote server offering installed debuginfo packages on-demand. They would appear as local files for the user's machine, allowing gdb to provide better backtraces and no core dumps would travel outside the user's machine.
Finally, I'd still prefer a way for the stack traces with mini-debug that should already be available on the system to be uploaded without interaction. Full debug traces could be sent out as additional information to those reports (whether they end up in Bugzilla or just on the ABRT server).
Yes, if you use the notification bubbles for reporting, then ABRT works as you describe. You can also enable the Auto-reporting to get rid of necessity to click "Report" button in the notification bubble:
https://github.com/abrt/abrt/wiki/Configuration#autoreporting
The new workflow disables Bugzilla (and all the tings before opening a new Bugzilla bug) when Shortened Reporting is ON for the reporting process started from the GUI.
This should probably be integrated in the Privacy Settings of the desktop instead of being in the bug reporting application's preferences.
Cheers
Hi.
I'll avoid quoting a whole bunch of stuff and get straight to the point: I agree with all the points Bastien raised.
Furthermore, I think it would be best if the problem will be reported *automatically*. You can allow the user to comment on the problem if they have anything to add directly from the notification ("The problem has been reported. [comment]"). The "comment" button would open a simple screen in which they'll be able to comment, but there shouldn't be a "progress" screen for comment submission - it should be done in the background. There's no real reason to make the user watch a progress screen when they report a comment, and no real reason for them to close the dialog manually.
Another thing worth considering is having a button in the notification to re-launch the program that crashed if it was a desktop app and not a background service.
Users should be able to disable this kind of automatic reporting in the privacy panel in Settings.
Ideally you want the reporting process to be un-intrusive and to take little to no time from the user. If you make the user wait more than a minute just to report an issue, they'll not do it again ever.
On Mon, 2014-08-11 at 15:58 +0300, Elad Alfassa wrote:
Hi.
I'll avoid quoting a whole bunch of stuff and get straight to the point: I agree with all the points Bastien raised.
Furthermore, I think it would be best if the problem will be reported *automatically*. You can allow the user to comment on the problem if they have anything to add directly from the notification ("The problem has been reported. [comment]"). The "comment" button would open a simple screen in which they'll be able to comment, but there shouldn't be a "progress" screen for comment submission - it should be done in the background. There's no real reason to make the user watch a progress screen when they report a comment, and no real reason for them to close the dialog manually.
That sounds good. I will try to implement it.
Another thing worth considering is having a button in the notification to re-launch the program that crashed if it was a desktop app and not a background service.
I have filed an upstream ticket for it: https://github.com/abrt/abrt/issues/833
Users should be able to disable this kind of automatic reporting in the privacy panel in Settings.
I have asked Bastien Nocera for a guidance on this: https://lists.fedoraproject.org/pipermail/desktop/2014-August/010099.html
Ideally you want the reporting process to be un-intrusive and to take little to no time from the user. If you make the user wait more than a minute just to report an issue, they'll not do it again ever.
Thank you for your great ideas!
Jakub
On Mon, 2014-08-11 at 08:31 -0400, Bastien Nocera wrote:
----- Original Message -----
Dear Bastien,
Thank you for the quick response!
On Mon, 2014-08-11 at 05:20 -0400, Bastien Nocera wrote:
Hello Jakub,
----- Original Message -----
Hello,
I am working on a new version of ABRT which should have Bugzilla disabled in GNOME by default. So, it won't be necessary to remove any package, everything will be done on ABRT side. Unfortunately, I cannot release the updated packages until we upgrade the Fedora's ABRT server. And I would rather hear some feedback before I push those changes to upstream.
See: https://github.com/abrt/abrt/wiki/GUI-Shortened-Reporting
Could you please explain what the differences are in the workflow?
My intention was to describe the new workflow on the page I sent in the first email:
https://github.com/abrt/abrt/wiki/GUI-Shortened-Reporting
Can you see the differences between "Shortened Reporting ON" (the new workflow) and "Shortened Reporting OFF" (the old workflow)?
I can see the difference, but I don't understand why I can't comment again after the first time I've commented.
I thought it would be a good idea to somehow indicate that the problem is completely handled (reported & commented). There were complains about "Report" button enabled for already reported problems. Should I make "Comment" button always enabled?
The process to skip commenting the first time is also sub-par. Given that the window is only there to show progress, maybe it doesn't need to be there at all, and progress can be shown in the main window.
I am going to be completely honest with you: I want/need/have to reuse the reporting window for several reporting work-flows because we have one for Fedora (ABRT Server/Bugzilla), SELinux AVCs, Anaconda (Bugzilla/Upload), RHEL and another distro in the near future.
Are you after a UI review after that?
You are the reviewer :) Thank you very much indeed!
One of the problems of having to input comments before the report is done is still there, and users still need to wait in front of the dialogue when reporting bugs against the ABRT server.
If you click "Report" in the notification bubble, no input is required and the reporting finishes immediately.
Why is the work-flow different in this case?
Our vision is the following:
The notification bubbles: - fast and simple reporting for users who don't want to go through the full reporting process but want to let maintainers know about crashing applications
The GUI: - for advanced users, they know the purpose of "Automatic Bug Reporting Tool", who wants to participate in the bug resolution process
Why would the user want *not* to report the bug?
OK, I wasn't precise, the reporting finishes immediately after sending an uReport.
Either do it automatically, or simply cache it all so that they can be reported by hand later, in the UI.
If you click "Report" in the GUI, the reporting window allows you to provide a description, informs you about processing and tells you that the reporting is done. The workflow is almost the same as the workflow for New Report in Normal mode at: https://wiki.gnome.org/Design/Apps/Oops
I don't see any windows besides the main window in those mockups. The "add comment" variant is only there for developers.
Although I would really love to make ABRT's workflow completely the same, I cannot do it because I need to reuse the reporting window for other work-flows (Fedora, SELinux, Anaconda, RHEL).
I guess the problem is that the reporting window isn't closed right after the click on "Send" button. I will try to fix it.
You could start reporting the backtrace straight away when clicking report, and appending a comment after that if the user deemed it necessary to do so.
Excellent idea, thank you! I'll give it a try.
I also note that the core dump uploading, which gdb engineers advised against,
Pardon? I am not sure I understand you. Where gdb engineers advised such a thing?
The gdb engineers, as well as security engineers, I talked to thought it was a bad thing for the core dump to even travel to a remote machine. The remote gdb could be vulnerable to a carefully crafted core dump, potentially gaining access to the server, and also other user's core dumps.
Even if the core dump generation using gdb on the remote server is secure, other services that it offers could be compromised and attackers could harvest passwords and other data from the core dumps.
ABRT warns users before uploading core dump and they can generate backtrace locally if they have concerns about security.
is still there for all the reports sent to the ABRT server.
No, the new workflow doesn't upload the core dump. If ABRT uploads the core dump, it is a bug or you don't have Shortened Reporting ON:
https://github.com/abrt/abrt/wiki/Configuration#shortened-reporting
Right, but that's still available when doing "shortened reporting off", no?
Yes, exactly. And GNOME user will do "Shortened reporting ON" by default.
I don't understand how one would switch between those 2 modes,
In the ABRT Preferences window. See: https://github.com/abrt/abrt/wiki/Configuration#shortened-reporting
or how they might know the difference.
It will be documented in the ABRT Preferences window, on the online documentation and in man pages.
I think that ABRT should be able to setup a fuse-like share to gather the debuginfo from, without having to upload a potentially huge core file. That also means that the process of unpacking/preparing the packages for gdb can be started much earlier (before the core dump would have reached the server in the old case).
Please, excuse my ignorance, but what is fuse-like share? How should it work together with ABRT?
User-space filesystem. You'd have a remote server offering installed debuginfo packages on-demand. They would appear as local files for the user's machine, allowing gdb to provide better backtraces and no core dumps would travel outside the user's machine.
I understand and we can implement it in the next step. IMHO it would required a broader discussion and some security expert should declare that this is acceptable solution.
Anyway, it is a very good idea. Thank you!
I have filed an upstream ticket for it: https://github.com/abrt/abrt/issues/832
Finally, I'd still prefer a way for the stack traces with mini-debug that should already be available on the system to be uploaded without interaction. Full debug traces could be sent out as additional information to those reports (whether they end up in Bugzilla or just on the ABRT server).
Yes, if you use the notification bubbles for reporting, then ABRT works as you describe. You can also enable the Auto-reporting to get rid of necessity to click "Report" button in the notification bubble:
https://github.com/abrt/abrt/wiki/Configuration#autoreporting
The new workflow disables Bugzilla (and all the tings before opening a new Bugzilla bug) when Shortened Reporting is ON for the reporting process started from the GUI.
This should probably be integrated in the Privacy Settings of the desktop instead of being in the bug reporting application's preferences.
Sure, what should I do to get this done?
I have attempted to develop a custom ABRT panel for control-center but I failed: https://mail.gnome.org/archives/gnomecc-list/2012-October/msg00017.html
Kind regards, Jakub
----- Original Message ----- <snip>
I thought it would be a good idea to somehow indicate that the problem is completely handled (reported & commented). There were complains about "Report" button enabled for already reported problems. Should I make "Comment" button always enabled?
If it's possible to add new comments, yes.
The process to skip commenting the first time is also sub-par. Given that the window is only there to show progress, maybe it doesn't need to be there at all, and progress can be shown in the main window.
I am going to be completely honest with you: I want/need/have to reuse the reporting window for several reporting work-flows because we have one for Fedora (ABRT Server/Bugzilla), SELinux AVCs, Anaconda (Bugzilla/Upload), RHEL and another distro in the near future.
I don't see what is, or should be different for the user about reporting SELinux AVCs to Bugzilla, reporting Anaconda traces to Bugzilla, or reporting crashers to ABRT.
Are you after a UI review after that?
You are the reviewer :) Thank you very much indeed!
I filed: https://github.com/abrt/gnome-abrt/issues/55 through to 67, to start with.
One of the problems of having to input comments before the report is done is still there, and users still need to wait in front of the dialogue when reporting bugs against the ABRT server.
If you click "Report" in the notification bubble, no input is required and the reporting finishes immediately.
Why is the work-flow different in this case?
Our vision is the following:
The notification bubbles:
- fast and simple reporting for users who don't want to go through the
full reporting process but want to let maintainers know about crashing applications
The GUI:
- for advanced users, they know the purpose of "Automatic Bug
Reporting Tool", who wants to participate in the bug resolution process
Why would the user want *not* to report the bug?
OK, I wasn't precise, the reporting finishes immediately after sending an uReport.
Either do it automatically, or simply cache it all so that they can be reported by hand later, in the UI.
If you click "Report" in the GUI, the reporting window allows you to provide a description, informs you about processing and tells you that the reporting is done. The workflow is almost the same as the workflow for New Report in Normal mode at: https://wiki.gnome.org/Design/Apps/Oops
I don't see any windows besides the main window in those mockups. The "add comment" variant is only there for developers.
Although I would really love to make ABRT's workflow completely the same, I cannot do it because I need to reuse the reporting window for other work-flows (Fedora, SELinux, Anaconda, RHEL).
That's really not a good enough reason for not wanting to change it.
<snip>
I also note that the core dump uploading, which gdb engineers advised against,
Pardon? I am not sure I understand you. Where gdb engineers advised such a thing?
The gdb engineers, as well as security engineers, I talked to thought it was a bad thing for the core dump to even travel to a remote machine. The remote gdb could be vulnerable to a carefully crafted core dump, potentially gaining access to the server, and also other user's core dumps.
Even if the core dump generation using gdb on the remote server is secure, other services that it offers could be compromised and attackers could harvest passwords and other data from the core dumps.
ABRT warns users before uploading core dump and they can generate backtrace locally if they have concerns about security.
Warning users doesn't make the retrace server secure. And there's currently no other ways to generate a backtrace with full debuginfo.
is still there for all the reports sent to the ABRT server.
No, the new workflow doesn't upload the core dump. If ABRT uploads the core dump, it is a bug or you don't have Shortened Reporting ON:
https://github.com/abrt/abrt/wiki/Configuration#shortened-reporting
Right, but that's still available when doing "shortened reporting off", no?
Yes, exactly. And GNOME user will do "Shortened reporting ON" by default.
Why wouldn't other users want to make use of the "shortened reporting"?
I don't understand how one would switch between those 2 modes,
In the ABRT Preferences window. See: https://github.com/abrt/abrt/wiki/Configuration#shortened-reporting
As I mentioned before, I'm not sure why users wouldn't want to have this feature on, all the time.
or how they might know the difference.
It will be documented in the ABRT Preferences window, on the online documentation and in man pages.
I still don't understand why we want to make this an option, so I'd like to know the difference now :)
<snip>
Finally, I'd still prefer a way for the stack traces with mini-debug that should already be available on the system to be uploaded without interaction. Full debug traces could be sent out as additional information to those reports (whether they end up in Bugzilla or just on the ABRT server).
Yes, if you use the notification bubbles for reporting, then ABRT works as you describe. You can also enable the Auto-reporting to get rid of necessity to click "Report" button in the notification bubble:
https://github.com/abrt/abrt/wiki/Configuration#autoreporting
The new workflow disables Bugzilla (and all the tings before opening a new Bugzilla bug) when Shortened Reporting is ON for the reporting process started from the GUI.
This should probably be integrated in the Privacy Settings of the desktop instead of being in the bug reporting application's preferences.
Sure, what should I do to get this done?
I have attempted to develop a custom ABRT panel for control-center but I failed: https://mail.gnome.org/archives/gnomecc-list/2012-October/msg00017.html
That's because, as I said above, and 2 years ago, it should be integrated into the Privacy panel, and it should only configure how to capture crashes (not at all, locally only, or report them automatically).
Adding something like ABRT's Preferences to gnome-control-center is out of the question.
Cheers
On Tue, 2014-08-12 at 12:21 -0400, Bastien Nocera wrote:
----- Original Message -----
<snip> > > The process to skip commenting the first time is > > also sub-par. Given that the window is only there to show progress, maybe > > it > > doesn't need to be there at all, and progress can be shown in the main > > window. > > I am going to be completely honest with you: I want/need/have to reuse > the reporting window for several reporting work-flows because we have > one for Fedora (ABRT Server/Bugzilla), SELinux AVCs, Anaconda > (Bugzilla/Upload), RHEL and another distro in the near future.
I don't see what is, or should be different for the user about reporting SELinux AVCs to Bugzilla, reporting Anaconda traces to Bugzilla, or reporting crashers to ABRT.
Reporting to ABRT server is fast and anonymous, thus the report doesn't need a review and doesn't need a comment. - the mockups cover this part
Reporting to Bugzilla isn't anonymous, automatically collected data migth contain security sensitive data and ABRT must ensure high quality of reports (maintainers are people too), thus the report must be reviewed, should have a comment and user must provide Bugzilla credentials. - the mockups don't cover this part at all (or am I mistaken?)
Are you after a UI review after that?
You are the reviewer :) Thank you very much indeed!
I filed: https://github.com/abrt/gnome-abrt/issues/55 through to 67, to start with.
Many thanks! I've fixed a lot of them and I'll fix the rest of those issues when gtk-3.14 is released.
Either do it automatically, or simply cache it all so that they can be reported by hand later, in the UI.
If you click "Report" in the GUI, the reporting window allows you to provide a description, informs you about processing and tells you that the reporting is done. The workflow is almost the same as the workflow for New Report in Normal mode at: https://wiki.gnome.org/Design/Apps/Oops
I don't see any windows besides the main window in those mockups. The "add comment" variant is only there for developers.
Although I would really love to make ABRT's workflow completely the same, I cannot do it because I need to reuse the reporting window for other work-flows (Fedora, SELinux, Anaconda, RHEL).
That's really not a good enough reason for not wanting to change it.
I'm not saying that I don't want to change it. I just said that it's hard to make it exactly the same and be able to support the other workflows. We all have to make trade-offs, right?
<snip> > > > > I also note that the core dump uploading, which gdb engineers advised > > > > against, > > > > > > Pardon? I am not sure I understand you. Where gdb engineers advised such > > > a thing? > > > > The gdb engineers, as well as security engineers, I talked to thought it > > was a bad thing for the core dump to even travel to a remote machine. The > > remote gdb could be vulnerable to a carefully crafted core dump, > > potentially > > gaining access to the server, and also other user's core dumps. > > > > Even if the core dump generation using gdb on the remote server is secure, > > other services that it offers could be compromised and attackers could > > harvest passwords and other data from the core dumps. > > ABRT warns users before uploading core dump and they can generate > backtrace locally if they have concerns about security.
Warning users doesn't make the retrace server secure. And there's currently no other ways to generate a backtrace with full debuginfo.
This topic is being discussed here : https://github.com/abrt/abrt/issues/834
is still there for all the reports sent to the ABRT server.
No, the new workflow doesn't upload the core dump. If ABRT uploads the core dump, it is a bug or you don't have Shortened Reporting ON:
https://github.com/abrt/abrt/wiki/Configuration#shortened-reporting
Right, but that's still available when doing "shortened reporting off", no?
Yes, exactly. And GNOME user will do "Shortened reporting ON" by default.
Why wouldn't other users want to make use of the "shortened reporting"?
We want to allow users of other DEs to report bugs to Bugzilla without the need to configure ABRT.
I don't understand how one would switch between those 2 modes,
In the ABRT Preferences window. See: https://github.com/abrt/abrt/wiki/Configuration#shortened-reporting
As I mentioned before, I'm not sure why users wouldn't want to have this feature on, all the time.
It would prevent users from submitting a full report to Bugzilla.
or how they might know the difference.
It will be documented in the ABRT Preferences window, on the online documentation and in man pages.
I still don't understand why we want to make this an option, so I'd like to know the difference now :)
ON -> automatic report (?comment) [ABRT server]
OFF -> automatic report (?comment) [ABRT server] + full report [Bugzilla]
<snip> > > > > Finally, I'd still prefer a way for the stack traces with mini-debug > > > > that > > > > should > > > > already be available on the system to be uploaded without interaction. > > > > Full > > > > debug > > > > traces could be sent out as additional information to those reports > > > > (whether they > > > > end up in Bugzilla or just on the ABRT server). > > > > > > Yes, if you use the notification bubbles for reporting, then ABRT works > > > as you describe. You can also enable the Auto-reporting to get rid of > > > necessity to click "Report" button in the notification bubble: > > > > > > https://github.com/abrt/abrt/wiki/Configuration#autoreporting > > > > > > The new workflow disables Bugzilla (and all the tings before opening a > > > new Bugzilla bug) when Shortened Reporting is ON for the reporting > > > process started from the GUI. > > > > This should probably be integrated in the Privacy Settings of the desktop > > instead > > of being in the bug reporting application's preferences. > > Sure, what should I do to get this done? > > I have attempted to develop a custom ABRT panel for control-center but I > failed: > https://mail.gnome.org/archives/gnomecc-list/2012-October/msg00017.html
That's because, as I said above, and 2 years ago, it should be integrated into the Privacy panel, and it should only configure how to capture crashes (not at all, locally only, or report them automatically).
Adding something like ABRT's Preferences to gnome-control-center is out of the question.
OK, I've understood for the first time, it wasn't necessary to elaborate more on that. I just wanted to express my will to work on this goal. Unfortunately, your response didn't help me much again. I'd rather know what is the preferred way of accomplishing this goal.
Thanks Elad for filing https://github.com/abrt/gnome-abrt/issues/74
Kind regards, Jakub
On Aug 11, 2014, at 5:19 AM, Jakub Filak jfilak@redhat.com wrote:
If you click "Report" in the notification bubble, no input is required and the reporting finishes immediately.
I think this needs some sort of visual feedback, like an animation, to indicate it went somewhere. I've been clicking this and because I wasn't getting the Abrt program launched, that the report functionality simply wasn't working. So I'd go dig out Abrt and manually report it.
Chris Murphy
On Aug 11, 2014, at 4:11 PM, Chris Murphy lists@colorremedies.com wrote:
On Aug 11, 2014, at 5:19 AM, Jakub Filak jfilak@redhat.com wrote:
If you click "Report" in the notification bubble, no input is required and the reporting finishes immediately.
I think this needs some sort of visual feedback, like an animation, to indicate it went somewhere. I've been clicking this and because I wasn't getting the Abrt program launched, that the report functionality simply wasn't working. So I'd go dig out Abrt and manually report it.
The other thing that's made me think it isn't reporting, is that when I click on the problem in Abrt, the Reported field says no.
Chris Murphy
On Mon, 2014-08-11 at 16:42 -0600, Chris Murphy wrote:
On Aug 11, 2014, at 4:11 PM, Chris Murphy lists@colorremedies.com wrote:
On Aug 11, 2014, at 5:19 AM, Jakub Filak jfilak@redhat.com wrote:
If you click "Report" in the notification bubble, no input is required and the reporting finishes immediately.
I think this needs some sort of visual feedback, like an animation, to indicate it went somewhere. I've been clicking this and because I wasn't getting the Abrt program launched, that the report functionality simply wasn't working. So I'd go dig out Abrt and manually report it.
The other thing that's made me think it isn't reporting, is that when I click on the problem in Abrt, the Reported field says no.
Oops, sorry, you probably hit a bug. Perhaps the ABRT server didn't return an expected response and the GUI was confused. We will fix it.
Regards, Jakub
On Tue, 2014-08-12 at 12:19 +0200, Jakub Filak wrote:
The other thing that's made me think it isn't reporting, is that
when I click on the problem in Abrt, the Reported field says no.
Oops, sorry, you probably hit a bug. Perhaps the ABRT server didn't return an expected response and the GUI was confused. We will fix it.
I think it always says "Reported No" until the problem is reported to Bugzilla. If shortened reporting is enabled, this should instead indicate whether it has been reported to the server. If shortened reporting is not enabled, then maybe having two different rows for the two different types of reporting would make sense?
On Mon, 2014-08-11 at 16:11 -0600, Chris Murphy wrote:
On Aug 11, 2014, at 5:19 AM, Jakub Filak jfilak@redhat.com wrote:
If you click "Report" in the notification bubble, no input is required and the reporting finishes immediately.
I think this needs some sort of visual feedback, like an animation, to indicate it went somewhere.
Isn't it enough to show another notification bubble stating that the problem has been reported?
Regards, Jakub
On Aug 12, 2014, at 4:11 AM, Jakub Filak jfilak@redhat.com wrote:
On Mon, 2014-08-11 at 16:11 -0600, Chris Murphy wrote:
On Aug 11, 2014, at 5:19 AM, Jakub Filak jfilak@redhat.com wrote:
If you click "Report" in the notification bubble, no input is required and the reporting finishes immediately.
I think this needs some sort of visual feedback, like an animation, to indicate it went somewhere.
Isn't it enough to show another notification bubble stating that the problem has been reported?
Maybe too much, if I have to click to dismiss.
The first time I click Report I get a message asking, to the effect, if I want reports sent automatically from now on. That message could be modified to say two things: a.) The problem report has been sent. b.) Should future problems be reported automatically also? Yes/No
This probably sufficiently conveys the first problem report was sent upon clicking Report, and it's just a new normal to get used to; where in the past normal was ABRT was launched.
Chris Murphy
On Tue, 2014-08-12 at 09:37 -0600, Chris Murphy wrote:
Maybe too much, if I have to click to dismiss.
The first time I click Report I get a message asking, to the effect, if I want reports sent automatically from now on. That message could be modified to say two things: a.) The problem report has been sent. b.) Should future problems be reported automatically also? Yes/No
I'm not sure it's right to send the first crash report before asking for permission....
On Aug 12, 2014, at 5:08 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Tue, 2014-08-12 at 09:37 -0600, Chris Murphy wrote:
Maybe too much, if I have to click to dismiss.
The first time I click Report I get a message asking, to the effect, if I want reports sent automatically from now on. That message could be modified to say two things: a.) The problem report has been sent. b.) Should future problems be reported automatically also? Yes/No
I'm not sure it's right to send the first crash report before asking for permission….
Umm? In this regard, I'm not suggesting it behave any differently than it does now: I get a notification of a problem which includes option to ignore or report; and by clicking the report button I'm giving it permission to send the report. My suggestion doesn't change any of this.
My suggestion is only to add a message to the existing one-time dialog that follows, indicating the report has been sent, per my previous request. This is in lieu of another dialog or notification telling me each time that the report I just asked to be sent has been sent, which I think is too much notifying and dismissing, to the point I'd sooner suggest no change to the existing behavior.
Chris Murphy
On Tue, 2014-08-12 at 20:08 -0600, Chris Murphy wrote:
Umm? In this regard, I'm not suggesting it behave any differently than it does now: I get a notification of a problem which includes option to ignore or report; and by clicking the report button I'm giving it permission to send the report. My suggestion doesn't change any of this.
My suggestion is only to add a message to the existing one-time dialog that follows, indicating the report has been sent, per my previous request. This is in lieu of another dialog or notification telling me each time that the report I just asked to be sent has been sent, which I think is too much notifying and dismissing, to the point I'd sooner suggest no change to the existing behavior.
Ah, right, that makes sense.
On Mon, 2014-08-11 at 04:07 -0400, Jakub Filak wrote:
Hello,
I am working on a new version of ABRT which should have Bugzilla disabled in GNOME by default. So, it won't be necessary to remove any package, everything will be done on ABRT side. Unfortunately, I cannot release the updated packages until we upgrade the Fedora's ABRT server. And I would rather hear some feedback before I push those changes to upstream.
See: https://github.com/abrt/abrt/wiki/GUI-Shortened-Reporting
Regards, Jakub
Hi Jakub,
I read your wiki page and I think this looks like a significant improvement. If you're able to release that upgrade prior to F21, as sounds likely, that would definitely resolve my concerns.
Bastien and Elrad's suggestions would also be good improvements.
Michael
On Mon, 2014-08-11 at 10:45 -0500, Michael Catanzaro wrote:
On Mon, 2014-08-11 at 04:07 -0400, Jakub Filak wrote:
Hello,
I am working on a new version of ABRT which should have Bugzilla disabled in GNOME by default. So, it won't be necessary to remove any package, everything will be done on ABRT side. Unfortunately, I cannot release the updated packages until we upgrade the Fedora's ABRT server. And I would rather hear some feedback before I push those changes to upstream.
See: https://github.com/abrt/abrt/wiki/GUI-Shortened-Reporting
Regards, Jakub
Hi Jakub,
I read your wiki page and I think this looks like a significant improvement. If you're able to release that upgrade prior to F21, as sounds likely, that would definitely resolve my concerns.
Bastien and Elrad's suggestions would also be good improvements.
Michael
Hi Michael,
Thank you very much for taking the time to read the wiki page!
I'll try to implement Bastien and Elrad's suggestions which I consider feasible for me to finish in the F21's time frame and I'll release the updated packages.
I'll keep you updated.
Kind regards, Jakub
Michael Catanzaro píše v Ne 10. 08. 2014 v 12:27 -0500:
On Wed, 2014-07-23 at 16:15 +0200, Richard Marko wrote:
As Jirka pointed out, retrace server is often overloaded to the point that retracing of small coredump takes very long time. The machine where it's hosted is also being upgraded so this shouldn't be an issue when the upgrade is in place.
Hey Richard and Workstation WG,
Reporting to Bugzilla is still extremely slow (I gave up on a report today after roughly 10 minutes of "preparing environment for backtrace generation). Unless this retrace server upgrade is coming very soon and is expected to produce an order of magnitude performance increase, then I think we should go ahead and disable reporting to Bugzilla in the meantime. We can do this by removing the gnome-abrt package while leaving the other abrt packages in place. Try this locally to see how it works -- ABRT will still process the crashes and send automatic crash reports to the retrace server, unobtrusively notifying the user when it has done so, but the problematic UI for reporting to Bugzilla will be gone.
There is one minor bug: once, by clicking on the notification in some particular way, I received a notification that said "Failed to launch abrt.desktop" (or something similar). It disappeared pretty quickly and I haven't managed to reproduce. Besides that problem, this seems like a good option to consider as the default for Workstation.
I heard at Flock that ABRT server should get some new machines from the Fedora infra which should speed up the service significantly. Fingers crossed :)
Jiri
On Mon, 11 Aug 2014 13:09:22 +0200 Jiri Eischmann eischmann@redhat.com wrote:
I heard at Flock that ABRT server should get some new machines from the Fedora infra which should speed up the service significantly. Fingers crossed :)
To chime in on that point and be more detailed:
We have 2 new machines that are already racked and networked. We just need to get the base OS installed and storage configured as the retrace folks want and then can hand them off. I imagine they will need a bit of time to setup things after that and then they should be able to go into service. So, it should be sometime in the next few weeks hopefully.
kevin
On Wed, 2014-07-16 at 10:59 +0200, Jiri Eischmann wrote:
ad 2) This is not slow at all. ureports are created and uploaded within seconds.
Thanks for bringing up the distinction here, by the way -- it's only reporting to Bugzilla that is so horribly broken. (I'm with Elrad -- I don't understand how people manage to complete the process nowadays.) I've never had any problem with the automatic reports, which are unobtrusive and always quick. The GUI claims that such crashes are "not reported" even after ABRT displays a notification to say it has been automatically reported, which is not OK, but that's a GUI problem.
What do you think about asking the ABRT devs to move the GUI to a subpackage that we will not install by default, so the user never sees anything besides notifications unless he installs the package manually?
On Wed, 2014-07-16 at 07:11 -0500, Michael Catanzaro wrote:
On Wed, 2014-07-16 at 10:59 +0200, Jiri Eischmann wrote:
ad 2) This is not slow at all. ureports are created and uploaded within seconds.
Thanks for bringing up the distinction here, by the way -- it's only reporting to Bugzilla that is so horribly broken. (I'm with Elrad -- I don't understand how people manage to complete the process nowadays.) I've never had any problem with the automatic reports, which are unobtrusive and always quick. The GUI claims that such crashes are "not reported" even after ABRT displays a notification to say it has been automatically reported, which is not OK, but that's a GUI problem.
What do you think about asking the ABRT devs to move the GUI to a subpackage that we will not install by default, so the user never sees anything besides notifications unless he installs the package manually?
I'm of two minds on this.
I agree that the retrace server with its automatically collected statistics is valuable. Imo, that is the one 'winner' that the abrt effort has produced. It would be great to focus on that part of the project, develop it more actively, and advertise it more so that it becomes part of the regular Fedora development culture - From my own experience, I look at it maybe every other month, and try to track down some crashes. It is not something I have constantly on my radar. Maybe it is different for others ?
But the client-side of abrt is so prone to quality of implementation issues that I might agree that it would be best to remove it and start over. Just the other day, I leisurely installed eclipse during a 'developer experience' presentation, only to find my laptop unresponsive after the meeting. Turns out abrt-java was eating my system :-(.
Matthias
On Wed, 2014-07-16 at 13:42 -0400, Matthias Clasen wrote:
But the client-side of abrt is so prone to quality of implementation issues that I might agree that it would be best to remove it and start over. Just the other day, I leisurely installed eclipse during a 'developer experience' presentation, only to find my laptop unresponsive after the meeting. Turns out abrt-java was eating my system :-(.
I don't usually work with Java, but when I do, I notice that ABRT automatically reports crashes against openjdk when my Java programs call into native code that crashes.
Anyway, I've emailed the crash-catcher list and pointed to this discussion.
...
But the client-side of abrt is so prone to quality of implementation issues that I might agree that it would be best to remove it and start over. ...
I agree that we need to address these user experience issues as a matter of urgency. We also need to drive up quality in Fedora of course, and that requires high-quality data on crashers. We need a plan to ensure that we get this.
The first step is to identify our requirements, as well as any verifiable issues that currently exist. (I know that Jon McCann did a lot of work in this area, so we're not starting from a blank slate.) Once we have that, we can have a conversation with the ABRT team. Disabling or not including ARBT in F21 *might* make sense, but that decision really needs to be made as part of a wider strategy, and it needs to be a decision that the ABRT team themselves participate in.
Discussions about dropping something from a release on the basis of anecdotal evidence isn't especially helpful. Likewise, having that discussion without the involvement of the concerned parties isn't a healthy way to do business, and could well sour the relations that we need to develop in order to produce the kind of product that we want.
Allan
On Thu, Jul 17, 2014 at 1:46 PM, Allan Day allanpday@gmail.com wrote:
...
But the client-side of abrt is so prone to quality of implementation issues that I might agree that it would be best to remove it and start over. ...
I agree that we need to address these user experience issues as a matter of urgency. We also need to drive up quality in Fedora of course, and that requires high-quality data on crashers. We need a plan to ensure that we get this.
The first step is to identify our requirements, as well as any verifiable issues that currently exist. (I know that Jon McCann did a lot of work in this area, so we're not starting from a blank slate.) Once we have that, we can have a conversation with the ABRT team. Disabling or not including ARBT in F21 *might* make sense, but that decision really needs to be made as part of a wider strategy, and it needs to be a decision that the ABRT team themselves participate in.
Discussions about dropping something from a release on the basis of anecdotal evidence isn't especially helpful. Likewise, having that discussion without the involvement of the concerned parties isn't a healthy way to do business, and could well sour the relations that we need to develop in order to produce the kind of product that we want.
Yes! Very well put. Thanks.
josh
On Thu, 2014-07-17 at 18:46 +0100, Allan Day wrote:
Discussions about dropping something from a release on the basis of anecdotal evidence isn't especially helpful. Likewise, having that discussion without the involvement of the concerned parties isn't a healthy way to do business, and could well sour the relations that we need to develop in order to produce the kind of product that we want.
Hi,
I've sent out [1]
[1] https://lists.fedorahosted.org/pipermail/crash-catcher/2014-July/005535.html
Michael Catanzaro mcatanzaro@gnome.org wrote: ...
I've sent out [1]
[1] https://lists.fedorahosted.org/pipermail/crash-catcher/2014-July/005535.html
...
A good first step would be to draw up a list of ARBT bugs that we feel are critical for the Workstation user experience (this one [1] immediately springs to mind.) We should also ensure that any critical issues have been reported. It would be fantastic if someone could take this on.
Second, we (or I...) need to do a design review to see where we are and where we want to be with regards to the problem reporting user experience. There is a lot of background material that we can draw on here [2].
Once we've done these two steps, we'll be in a position to have a constructive conversation with the ABRT team.
There is also a more general issue here: traditionally, the Fedora release process has had a fairly limited definition of what constitutes a blocker, and there isn't a huge amount of downstream bug tracking in the run up to a release. If we want to raise the quality of the overall workstation experience, we'll need to expand the range of issues that are tracked for each release to include more general user experience bugs. This might well require changes to the workstation release process, as well as new release management roles.
Allan
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1050154 [2] https://wiki.gnome.org/Design/OS/ProblemReporting
On Thu, 2014-07-17 at 20:56 +0100, Allan Day wrote:
A good first step would be to draw up a list of ARBT bugs that we feel are critical for the Workstation user experience (this one [1] immediately springs to mind.) We should also ensure that any critical issues have been reported. It would be fantastic if someone could take this on.
OK. My list of critical bugs is small, but each one is very serious. You already mentioned [1]. I will add to that [2] and [3]. [2] is fairly new but occurs immediately nearly every time I report a bug, causing the report to fail. [3] used to cause reports to fail at the very end of the (excruciatingly long) bug report process roughly 50-80% of the time, but nowadays I cannot get past [2].
[4] looks like a duplicate of [3], but I list it here because I filed [3] specifically regarding Epiphany crashes, but (prior to the introduction of [2] it would) regularly occurs for other programs as well.
[5] is the "bug of general slowness" I mentioned earlier. I need to make a correction: earlier in this thread I claimed reporting a WebKit bug took me 40 minutes, and a gnote bug 15 minutes. In fact, reporting a Nautilus bug took 40 minutes, and the gnote bug a much more reasonable 5 minutes. (I haven't timed a WebKit bug like I thought I had, but I estimate it to be comparable in length.)
So that's four distinct bugs that I consider critical. I'll add on [6], which doesn't happen to me very often, but I feel is worth mentioning here. Beyond these, there are several design issues and minor bugs with ABRT's GUI that need work, but I don't think are sufficiently serious to block on or mention here. I've reported bugs for a few of few of these in the past, and I'll do a couple more today.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1050154 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1109697 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1047556 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1055627 [5] https://bugzilla.redhat.com/show_bug.cgi?id=1055335 [6] https://bugzilla.redhat.com/show_bug.cgi?id=1047550
Second, we (or I...) need to do a design review to see where we are and where we want to be with regards to the problem reporting user experience. There is a lot of background material that we can draw on here [2].
Once we've done these two steps, we'll be in a position to have a constructive conversation with the ABRT team.
My apologies to the ABRT team if my comments were at times too harsh or nonconstructive. I'm hoping my comments help improve the default user experience of Fedora Workstation and ABRT.
There is also a more general issue here: traditionally, the Fedora release process has had a fairly limited definition of what constitutes a blocker, and there isn't a huge amount of downstream bug tracking in the run up to a release. If we want to raise the quality of the overall workstation experience, we'll need to expand the range of issues that are tracked for each release to include more general user experience bugs. This might well require changes to the workstation release process, as well as new release management roles.
Allan, I absolutely agree with you. Don't forget about updates, though: all the pre-release validation in the world won't help if the updates repository is the wild west.
On Thu, 2014-07-17 at 16:26 -0500, Michael Catanzaro wrote:
OK. My list of critical bugs is small, but each one is very serious. You already mentioned [1]. I will add to that [2] and [3]. [2] is fairly new but occurs immediately nearly every time I report a bug, causing the report to fail.
[2] seems to have been recently fixed. This should dramatically improve the reliability of Bugzilla reports. Yay!
(Jakub has also fixed a plethora of smaller issues that I reported.)
Michael Catanzaro mcatanzaro@gnome.org wrote: ...
[2] seems to have been recently fixed. This should dramatically improve the reliability of Bugzilla reports. Yay!
(Jakub has also fixed a plethora of smaller issues that I reported.)
That's great news! Thanks for following up on this - the reports are really helpful. I'll do some work on this myself, once I've cleared some time.
Allan
Want to weigh in on this soon. Making sure I get a clean boot from F20, going to put my white hat back on and figure everything out (at least by being a crash test dummy/kernel thrasher/low security guinea pig).
Might have questions too, if anyone is nice enough to be patient with someone who hasn't been totally comfy since F16.
------ Powered by:
On Thursday, July 17, 2014 12:56 PM, Allan Day allanpday@gmail.com wrote:
Michael Catanzaro mcatanzaro@gnome.org wrote: ...
I've sent out [1]
[1] https://lists.fedorahosted.org/pipermail/crash-catcher/2014-July/005535.html
...
A good first step would be to draw up a list of ARBT bugs that we feel are critical for the Workstation user experience (this one [1] immediately springs to mind.) We should also ensure that any critical issues have been reported. It would be fantastic if someone could take this on.
Second, we (or I...) need to do a design review to see where we are and where we want to be with regards to the problem reporting user experience. There is a lot of background material that we can draw on here [2].
Once we've done these two steps, we'll be in a position to have a constructive conversation with the ABRT team.
There is also a more general issue here: traditionally, the Fedora release process has had a fairly limited definition of what constitutes a blocker, and there isn't a huge amount of downstream bug tracking in the run up to a release. If we want to raise the quality of the overall workstation experience, we'll need to expand the range of issues that are tracked for each release to include more general user experience bugs. This might well require changes to the workstation release process, as well as new release management roles.
Allan
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1050154 [2] https://wiki.gnome.org/Design/OS/ProblemReporting
On Mon, 2014-07-14 at 11:38 -0400, Christian Schaller wrote:
Well as annoying abrt can be I think nothing ruins the user experience more than crashers, so if abrt helps us fix more crashers/the most important crashers, I think that improvement in user experience probably outweighs the irritation of abrt.
My biggest problem with ABRT as a developer is it reports crashers to the wrong Bugzilla.
I and I think many other GNOME developers would strongly prefer all bug reports go directly upstream, instead of to Fedora's Bugzilla where they then have to be manually moved upstream (or just left to rot).
Having bugs for a given component distributed across multiple bug trackers just creates more work for upstream developers who double as package maintainers.
I requested long ago that package maintainers should be able to specify where ABRT sends crash reports for their own packages. I even suggested a possible mechanism for this, but I don't think it ever went anywhere.
https://fedorahosted.org/abrt/ticket/124
Matt
Well I don't think it is worthwhile chasing the abrt bugs through bugzilla, regardless of which bugzilla it uses. The true value of abrt is the data that is collected and can be viewed through: http://retrace.fedoraproject.org/faf/summary/
Because by looking at the 'problems' tab you will quite quickly see which crashers are hitting a lot of your users and are the ones making the distro seem unstable.
Despite its shortcomings it is worthwhile to note that abrt catches between 5000 and 10 000 crashers a day, even going up to almost 24 000 one day for f20. So I think it does provide enough data to help us improve our quality. I know a lot of developers (and managers) are checking the retrace data regularly and use it to prioritize which bugs are looked at first.
So instead of looking into dropping it we should if needed instead try to see if we can try to help the ABRT team improve it further.
Christian
----- Original Message -----
From: "Matthew Barnes" mbarnes@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Monday, July 14, 2014 10:22:12 PM Subject: Re: ABRT?
On Mon, 2014-07-14 at 11:38 -0400, Christian Schaller wrote:
Well as annoying abrt can be I think nothing ruins the user experience more than crashers, so if abrt helps us fix more crashers/the most important crashers, I think that improvement in user experience probably outweighs the irritation of abrt.
My biggest problem with ABRT as a developer is it reports crashers to the wrong Bugzilla.
I and I think many other GNOME developers would strongly prefer all bug reports go directly upstream, instead of to Fedora's Bugzilla where they then have to be manually moved upstream (or just left to rot).
Having bugs for a given component distributed across multiple bug trackers just creates more work for upstream developers who double as package maintainers.
I requested long ago that package maintainers should be able to specify where ABRT sends crash reports for their own packages. I even suggested a possible mechanism for this, but I don't think it ever went anywhere.
https://fedorahosted.org/abrt/ticket/124
Matt
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
----- Original Message -----
Well I don't think it is worthwhile chasing the abrt bugs through bugzilla, regardless of which bugzilla it uses. The true value of abrt is the data that is collected and can be viewed through: http://retrace.fedoraproject.org/faf/summary/
Because by looking at the 'problems' tab you will quite quickly see which crashers are hitting a lot of your users and are the ones making the distro seem unstable.
Despite its shortcomings it is worthwhile to note that abrt catches between 5000 and 10 000 crashers a day, even going up to almost 24 000 one day for f20. So I think it does provide enough data to help us improve our quality. I know a lot of developers (and managers) are checking the retrace data regularly and use it to prioritize which bugs are looked at first.
It's not as useful as you make it seem. There are things that can be fixed, certainly but there are also a number of those crashers for which there won't be an obvious answer, the result of a bug earlier in the code, and no way to reproduce the problem, contact the bug submitter, or get more information.
So instead of looking into dropping it we should if needed instead try to see if we can try to help the ABRT team improve it further.
Well as annoying abrt can be I think nothing ruins the user experience more than crashers, so if abrt helps us fix more crashers/the most important crashers, I think that improvement in user experience probably outweighs the irritation of abrt.
Crashes are bad enough. Piling up a terrible UI on top of that makes it even worse.
Cheers, Debarshi
Hi
On Tue, Jul 15, 2014 at 8:44 AM, Debarshi Ray wrote:
Crashes are bad enough. Piling up a terrible UI on top of that makes it even worse.
Perhaps but I have been hearing about the UI issues for a very long time without any effort spent on addressing them in a constructive fashion. The functionality is obviously desirable. So how about assigning a UI expert to spend sometime with the Abrt team?
Rahul
----- Original Message -----
Hi
On Tue, Jul 15, 2014 at 8:44 AM, Debarshi Ray wrote:
Crashes are bad enough. Piling up a terrible UI on top of that makes it even worse.
Perhaps but I have been hearing about the UI issues for a very long time without any effort spent on addressing them in a constructive fashion. The functionality is obviously desirable. So how about assigning a UI expert to spend sometime with the Abrt team?
Jon spent a long time with the ABRT team to present the requirements, mockups, etc. when ABRT was being spun up. The mockups are still available and open for review: https://wiki.gnome.org/Design/Apps/Oops and https://wiki.gnome.org/Design/OS/ProblemReporting
I think that many good points have been raised in this discussion.
I'm also in favor of removing ABRT for F21 and reconsidering in F22.
On 05/29/2014 02:32 PM, Lukáš Tinkl wrote:
based on request of cschaller, I'm sending the proposed list of Qt/Qt5 packages to be included in Fedora Workstation:
Is this supposed to be a list of source packages (so that all subpackages are included implicitly), or do you intend to include the listed (sub)packages only? If the latter, why don't you include the -devel packages?
On 05/29/2014 08:32 AM, Lukáš Tinkl wrote:
Hi, based on request of cschaller, I'm sending the proposed list of Qt/Qt5 packages to be included in Fedora Workstation:
qt qt-x11 qt-settings
qt5-qtbase qt5-qtimageformats qt5-qtsvg qt5-qtx11extras qt5-qtxmlpatterns qt5-qtdeclarative qt5-qtquickcontrols qt5-qtdoc qt5-qtconnectivity qt5-qtmultimedia qt5-qtgraphicaleffects
(you can see the dep chain of qt5 packages here: https://fedoraproject.org/wiki/KDE_updates)
+1 from me
cheers, ryanlerch
On 05/29/2014 02:32 PM, Lukáš Tinkl wrote:
Hi, based on request of cschaller, I'm sending the proposed list of Qt/Qt5 packages to be included in Fedora Workstation:
Hi Lukáš,
I am not very familiar with qt5. Any chance you could expand a little bit on why each of those packages would be useful to have on the Workstation image?
For example, why is qt5-qtdoc included? Would any end user ever go to /usr/share/doc/qt5/qtdoc/ and read what's there, e.g. why-moc.html?
Or why is qt5-qtx11extras there? Would we want to define qtx11extras as part of the base platform for the foreseeable future, given that we're slowly switching away from X11?
I myself can think of three general reasons for including Qt packages:
1) To make sure we have all the required components installed for proper Qt app theming under GNOME Shell;
2) To make sure plugins, e.g. various image loaders are installed because apps are likely to not have explicit dependencies on those.
3) To define a base platform that 3rd party apps could rely on; we'd make sure to avoid breaking ABI once we define something as part of the platform.
Thanks, Kalev
desktop@lists.fedoraproject.org
-
Alberto Ruiz -
Allan Day -
Araluen -
Bastien Nocera -
Chris Murphy -
Christian Schaller -
Cole Robinson -
David Tardon -
Debarshi Ray -
drago01 -
Elad Alfassa -
Florian Weimer -
Giovanni Campagna -
Jakub Filak -
Jiri Eischmann -
Josh Boyer -
Kalev Lember -
Kevin Fenzi -
Lars Seipel -
Lukáš Tinkl -
matt palsson -
Matthew Barnes -
Matthew Garrett -
Matthew Miller -
Matthias Clasen -
Michael Catanzaro -
Michael Cronenworth -
Michael Stahl -
Paul W. Frields -
quickbooks office -
Rahul Sundaram -
Richard Marko -
Richard Turner -
Ryan Lerch -
Thomas Gilliard