[opensuse-kde] Bug Fixing Apper and Testing
I have spent about 20+ man hours documenting and taking screen shots with respect to APPER and the enormity of its failing included in Opensuse 12.2. I would like to work with this application to get all the bugs out IF APPER is going to be maintained in 13.? As a newby to this list, how do I help with this information and to work with someone who maintains the code. -- Opensuse-KDE-Developer-Interface Testing and Debugging - Scott Couston -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
I would like to work with this application to get all the bugs out IF APPER is going to be maintained in 13.?
As a newby to this list, how do I help with this information and to work with someone who maintains the code.
I think it's a safe bet that Apper will be used in 13.1. As for 13.2, I'm not sure. The author of Apper is Daniel Nicoletti -- a guy who gets easily distracted by random things. He hasn't made his mail address public on https://projects.kde.org/apper so no idea how to reach him. I guess there's an Apper mailing list somewhere on kde.org. My personal opinion is that the future of package management for KDE-based Linux distros is Muon. It simply has more developers and one is being paid to work full-time on it. A PackageKit back-end for Muon is currently in development as a GSoC project. Once the summer is over, you could help with that. Or you could write a zypper back-end for Muon without the PackageKit layer. That one could be started right now because it would interfere with no one's GSoC project. The contact addresses are public under https://projects.kde.org/muon Markus -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data mercoledì 17 luglio 2013 03:44:45, Markus ha scritto: Hello Markus and Scott,
I would like to work with this application to get all the bugs out IF APPER is going to be maintained in 13.?
To be honest, Apper is quite different in 12.3 and 13.1: in 12.2 we had to stick to a very old version due to the fact that the zypper backend for PackageKit wasn't compatible (sadly PK doesn't promise a stable API and ABI, last time I checked). It got updated at one of the latest openSUSE hackatons and such it is much better in state than in 12.2.
to work full-time on it. A PackageKit back-end for Muon is currently in development as a GSoC project. Once the summer is over, you could help with
To be honest, and this is no way dissing the people working on Muon since they're quite good people, we can consider it once it's done. Switching *again* without a proper risk/benefit assessment is not going to work too well.
that. Or you could write a zypper back-end for Muon without the PackageKit
The problem is indeed in "you". It's not enough to write a zypper backend, it's important that it is *maintained*. A one-shot effort will lead us again to the same situation as 12.2. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
Am Mittwoch, 17. Juli 2013, 07:31:44 schrieb Luca Beltrame:
To be honest, and this is no way dissing the people working on Muon since they're quite good people, we can consider it once it's done. Switching *again* without a proper risk/benefit assessment is not going to work too well.
Obviously. That's why my comment wasn't about 13.1 but 13.2. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
-- Opensuse-KDE-Developer-Interface Testing and Debugging - Scott Couston On Wed, 2013-07-17 at 15:57 +0200, Markus wrote:
Am Mittwoch, 17. Juli 2013, 07:31:44 schrieb Luca Beltrame:
To be honest, and this is no way dissing the people working on Muon since they're quite good people, we can consider it once it's done. Switching *again* without a proper risk/benefit assessment is not going to work too well.
Obviously. That's why my comment wasn't about 13.1 but 13.2.
Marcus I am happy with the view of APPER not progressing into 13.1 and a New GSoC project. My thought are similar that there is far too much content that had a wide range of Bugs we inherit. APPER fails to observe our standard X Windows conventions. You cant patch over fundamental problems that start for this lack of adherence to X Windows GUI Standards. My private opinion is that we have too much content that has errors across the whole range of projects rather than a standard project that has fewer offering that works perfectly from day 1 of Official Release. Where are offering Swiss Cheese when you should offer Jarlsberg cheese..OMH!...I dont mean any disrespect to an country itself... I think, be starting afresh with maintainable software with maintainable conventions a good thing. We got to stop trying to patch up after patch up after patch up code that has fundamental adherence to convention and fundamental flaws in design. Happy to test what ever becomes of the packet manager...thanks -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
-- Opensuse-KDE-Developer-Interface Testing and Debugging - Scott Couston On Thu, 2013-07-18 at 10:02 +1000, Information - General wrote:
-- Opensuse-KDE-Developer-Interface Testing and Debugging - Scott Couston
On Wed, 2013-07-17 at 15:57 +0200, Markus wrote:
Am Mittwoch, 17. Juli 2013, 07:31:44 schrieb Luca Beltrame:
To be honest, and this is no way dissing the people working on Muon since they're quite good people, we can consider it once it's done. Switching *again* without a proper risk/benefit assessment is not going to work too well.
Obviously. That's why my comment wasn't about 13.1 but 13.2.
Marcus I am happy with the view of APPER not progressing into 13.1 and a New GSoC project.
My thought are similar that there is far too much content that had a wide range of Bugs we inherit. APPER fails to observe our standard X Windows conventions. You cant patch over fundamental problems that start for this lack of adherence to X Windows GUI Standards.
My private opinion is that we have too much content that has errors across the whole range of projects rather than a standard project that has fewer offering that works perfectly from day 1 of Official Release.
Where are offering Swiss Cheese when you should offer Jarlsberg cheese..OMH!...I dont mean any disrespect to an country itself...
I think, be starting afresh with maintainable software with maintainable conventions a good thing. We got to stop trying to patch up after patch up after patch up code that has fundamental adherence to convention and fundamental flaws in design.
Happy to test what ever becomes of the packet manager...thanks
I have further thoughts on APPER as a software management tool. Firstly, I think its a given that none of this code was written to conform to our current X-Windows standards. Using APPER as a software management tool is even more frightening for a development let alone a user perspective as installing software from APPER launches requests for root authority that are minimised and not in-focus. A user would not be able to find a minimised and out of focus plus escalation password minimised, out of focus and underneath the window in current focus. As a software Management tool there is a diverse range of selecting predefined groupings that fit into some grouping candidacy. If I select 'security' in the software manager I'm dumped with a list that comes from ???? predefined package list. Here I don’t have the opportunity to not show development and debug, non-32bit related and possibly non dependant listings, nor change of vendor no ability to keeping the file non-deleted or deleted (clean-up) afterwards. In this scenario, the user selects, deselected and deletes software based on a completely new unstandardised way of managing X-Windows. The scenario of installing the users selected packages goes through a trial run to confirm dependency issues at the last state before actual installation. The user is then presented only with cut and paste memory of the details of dependency issues,for the user to deselect or delete a package on the first selection list but only 1 at a time. Many dependency issues found in 'simulated runs' are solved one at a time per simulated run. If the user gets past the simulated test for dependency, auto associated dependant package appears in a huge list; mostly to install ever 32-bit version of selected native 64bit software. Well may we say, 'God save the Queen' because nothing will save apper from patch after patch of non conformance to GUI convention we established in the 11.x...versions...Having just put my foot in my mouth, I mean no disrespect to Her Majesty and the Royal House of Windsor.. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
participants (3)
-
Information - General -
Luca Beltrame -
Markus