We've got a draft of what we're considering as the target audience for what the fedora kde-sig produces.
https://fedoraproject.org/wiki/SIGs/KDE/KDE_Target_Audience
Comments?
-- Rex
On 16/03/10 16:55, Rex Dieter wrote:
We've got a draft of what we're considering as the target audience for what the fedora kde-sig produces.
https://fedoraproject.org/wiki/SIGs/KDE/KDE_Target_Audience
Comments?
As a current consumer of Fedora/KDE for our research group, your target audience fits us well, and the SOP looks good.
Thanks for a continuing great kde experience in Fedora.
Roderick
Rex Dieter wrote:
We've got a draft of what we're considering as the target audience for what the fedora kde-sig produces.
https://fedoraproject.org/wiki/SIGs/KDE/KDE_Target_Audience
Comments?
# Users who want access to the latest and greatest KDE has to offer # Users wishing to contribute to KDE development
+lots to those :-).
Thanks for your efforts.
Rex Dieter wrote:
We've got a draft of what we're considering as the target audience
Comments?
home user with some educational/career use stability is important (but can handle a glitch in order to get to enjoy the latest technologies now, but cannot handle a total failure to boot, as is typical of rawhide, as I need basic functionality always) rate of kde (and all other fedora) related updates is of great appeal general distro familiarity (used for eons and no interest in changing to .deb or other distro style of relearning all the /etc and etc. stuff)
Yup, those are important to me and I am definitely a target consumer.
On 16 March 2010 16:55, Rex Dieter <> wrote:
We've got a draft of what we're considering as the target audience for what the fedora kde-sig produces.
https://fedoraproject.org/wiki/SIGs/KDE/KDE_Target_Audience
Comments?
This Project now has an identity crisis. I've read this and the boards target audience & both don't change a single thing which doesn't happen already or is all this about writing down current policy? I don't get it.
You also asked what I want from a kde (linux) distro: * Polish, no ui bugs in your face * Integration, kde apps/front-ends/services by default (an issue only in gnome shops) * Community, users supporting users * Developers, developing the latest & greatest
...dex
On 03/17/2010 02:54 PM, dexter wrote:
On 16 March 2010 16:55, Rex Dieter<> wrote:
We've got a draft of what we're considering as the target audience for what the fedora kde-sig produces.
https://fedoraproject.org/wiki/SIGs/KDE/KDE_Target_Audience
Comments?
This Project now has an identity crisis. I've read this and the boards target audience& both don't change a single thing which doesn't happen already or is all this about writing down current policy?
I guess that's part of it. To clearly document and describe what fedora is all about. Prior to this arduous task, there was no clear focus or identity. Once this is in place, it's much easier to identify goals (and policies, etc) supporting those values.
-- Rex
dexter wrote:
- Integration, kde apps/front-ends/services by default (an issue only
in gnome shops)
I also think we should stress that. For example, it has been recently suggested to ship gnome-packagekit as the default updater even on the KDE spin, I think that would run very much counter to most users' expectations (including mine). We should only consider shipping GNOME apps when there's really no KDE alternative. People who want GNOME apps should use the GNOME spin. :-)
Kevin Kofler
On Wed, Mar 17, 2010 at 11:38 PM, Kevin Kofler kevin.kofler@chello.at wrote:
dexter wrote:
- Integration, kde apps/front-ends/services by default (an issue only
in gnome shops)
I also think we should stress that. For example, it has been recently suggested to ship gnome-packagekit as the default updater even on the KDE spin, I think that would run very much counter to most users' expectations (including mine). We should only consider shipping GNOME apps when there's really no KDE alternative. People who want GNOME apps should use the GNOME spin. :-)
Since i was the one who suggested it.. :) I do understand you but, if the KDE alternative is just giving a very basic functionality and is having problems (VPN IIRC) then we should consider using what works well, gives more output, does not suggest (again at the beginning of an update to reboot) stupid things.
KPK is in my eyes, ugly, unreliable and too basic. I suggested to you as well to try the latest GNOME-packagekit to see what i mean. I think KPK is on it's way, but not yet ready.
If we dont want to lose users to GNOME because of not fully working, suggesting stupid things KDE apps, we might better use the alternative, even if it's written GTK/GTK+. By the way, should everybody use the GNOME SPIN as well because there are no QT alternatives for the installed system-config-* utility's in the KDE SPIN? ;)
Thomas Janssen wrote:
Since i was the one who suggested it.. :) I do understand you but, if the KDE alternative is just giving a very basic functionality and is having problems (VPN IIRC) then we should consider using what works well, gives more output, does not suggest (again at the beginning of an update to reboot) stupid things.
Uh, VPN problems are a NM/KNM issue, not a KPK one.
The "suggests a reboot too early" bug is bizarre indeed, I should look if I can silence those reboot prompts. (I'm for silencing them entirely, KDE users are smart enough to know when they need to restart their computer. ;-) It'd also probably be the fastest way to zap that bug once and for all.)
Another thing I noticed is that KPK doesn't recognize different update types anymore after the latest PK update. :-(
I think what needs to happen here is that more people need to test PK updates in testing and that those updates need to be BLOCKED from getting pushed to stable if they break KPK. Throwing out KPK is entirely the wrong solution for such regressions introduced by PK updates. (Neither of the above bugs happened before the latest PK update. It's not KPK's fault that PK breaks backwards compatibility under it.)
One problem is that PK/KPK (and GPK, too) moves so fast that, even when I'm running the latest Fedora release, I'm still always running an already deprecated branch, so spending time fixing things might not pay off. (But on the other hand, F12 still has 9 months or so to live, so I guess fixing F12 issues is beneficial in any case.)
KPK is in my eyes, ugly, unreliable and too basic. I suggested to you as well to try the latest GNOME-packagekit to see what i mean. I think KPK is on it's way, but not yet ready.
Yet KPK just works. (Neither of the above 2 bugs is a showstopper, they're just minor annoyances that can be easily worked around.)
If we dont want to lose users to GNOME because of not fully working, suggesting stupid things KDE apps, we might better use the alternative, even if it's written GTK/GTK+. By the way, should everybody use the GNOME SPIN as well because there are no QT alternatives for the installed system-config-* utility's in the KDE SPIN? ;)
We actually do have alternatives for some of them, but the GTK+ app gets dragged in by Anaconda's dependencies. :-( For example, there is KUser in kdeadmin which can be used instead of system-config-users. This Anaconda dependency bloat is one of the unsolved problems. Others are stuff I use once and never again (e.g. system-config-selinux, to turn the crap off and never look at it again). It's not the same as a package updater which users will be running daily.
Kevin Kofler
Thomas Janssen wrote:
Since i was the one who suggested it.. :) I do understand you but, if the KDE alternative is just giving a very basic functionality and is having problems (VPN IIRC) then we should consider using what works well, gives more output, does not suggest (again at the beginning of an update to reboot) stupid things.
Uh, VPN problems are a NM/KNM issue, not a KPK one.
The "suggests a reboot too early" bug is bizarre indeed, I should look if I can silence those reboot prompts. (I'm for silencing them entirely, KDE users are smart enough to know when they need to restart their computer. ;-) It'd also probably be the fastest way to zap that bug once and for all.)
Another thing I noticed is that KPK doesn't recognize different update types anymore after the latest PK update. :-(
I think what needs to happen here is that more people need to test PK updates in testing and that those updates need to be BLOCKED from getting pushed to stable if they break KPK. Throwing out KPK is entirely the wrong solution for such regressions introduced by PK updates. (Neither of the above bugs happened before the latest PK update. It's not KPK's fault that PK breaks backwards compatibility under it.)
One problem is that PK/KPK (and GPK, too) moves so fast that, even when I'm running the latest Fedora release, I'm still always running an already deprecated branch, so spending time fixing things might not pay off. (But on the other hand, F12 still has 9 months or so to live, so I guess fixing F12 issues is beneficial in any case.)
KPK is in my eyes, ugly, unreliable and too basic. I suggested to you as well to try the latest GNOME-packagekit to see what i mean. I think KPK is on it's way, but not yet ready.
Yet KPK just works. (Neither of the above 2 bugs is a showstopper, they're just minor annoyances that can be easily worked around.)
Hi, Sure? In F12 the latest PackageKit (0.5.7-1) have broken kpackagekit's automatic update notification. In F13 automatic notification didn't ever work. And in Rawhide/F14 I had to remove kpackagekit to update my system. Are these 'minor annoyances'? (I know, bz them... :-))
PackageKit develops very fast, that's great. But I get the impression that the developers/maintainers are not too good in communicating what they are doing/changing. This must be very frustrating for the kpackagekit developers/maintainers to keep up with these changes. I don't like to have gnome-PackageKit in KDE either. I miss programming capabilities, but if I had them I would create an alternative not depending on PackageKit. IMHO, a package manager is a very critical app. What about reviving the package manager that lived in kde 3?
Martin Kho
If we dont want to lose users to GNOME because of not fully working, suggesting stupid things KDE apps, we might better use the alternative, even if it's written GTK/GTK+. By the way, should everybody use the GNOME SPIN as well because there are no QT alternatives for the installed system-config-* utility's in the KDE SPIN? ;)
We actually do have alternatives for some of them, but the GTK+ app gets dragged in by Anaconda's dependencies. :-( For example, there is KUser in kdeadmin which can be used instead of system-config-users. This Anaconda dependency bloat is one of the unsolved problems. Others are stuff I use once and never again (e.g. system-config-selinux, to turn the crap off and never look at it again). It's not the same as a package updater which users will be running daily.
Kevin Kofler
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On 20 March 2010 11:00, Martin Kho lists.kho@gmail.com wrote:
Thomas Janssen wrote:
Since i was the one who suggested it.. :) I do understand you but, if the KDE alternative is just giving a very basic functionality and is having problems (VPN IIRC) then we should consider using what works well, gives more output, does not suggest (again at the beginning of an update to reboot) stupid things.
Uh, VPN problems are a NM/KNM issue, not a KPK one.
The "suggests a reboot too early" bug is bizarre indeed, I should look if I can silence those reboot prompts. (I'm for silencing them entirely, KDE users are smart enough to know when they need to restart their computer. ;-) It'd also probably be the fastest way to zap that bug once and for all.)
Another thing I noticed is that KPK doesn't recognize different update types anymore after the latest PK update. :-(
I think what needs to happen here is that more people need to test PK updates in testing and that those updates need to be BLOCKED from getting pushed to stable if they break KPK. Throwing out KPK is entirely the wrong solution for such regressions introduced by PK updates. (Neither of the above bugs happened before the latest PK update. It's not KPK's fault that PK breaks backwards compatibility under it.)
One problem is that PK/KPK (and GPK, too) moves so fast that, even when I'm running the latest Fedora release, I'm still always running an already deprecated branch, so spending time fixing things might not pay off. (But on the other hand, F12 still has 9 months or so to live, so I guess fixing F12 issues is beneficial in any case.)
KPK is in my eyes, ugly, unreliable and too basic. I suggested to you as well to try the latest GNOME-packagekit to see what i mean. I think KPK is on it's way, but not yet ready.
Yet KPK just works. (Neither of the above 2 bugs is a showstopper, they're just minor annoyances that can be easily worked around.)
Hi, Sure? In F12 the latest PackageKit (0.5.7-1) have broken kpackagekit's automatic update notification. In F13 automatic notification didn't ever work. And in Rawhide/F14 I had to remove kpackagekit to update my system. Are these 'minor annoyances'? (I know, bz them... :-))
Two corrections: (1) F13 = Rawhide/F14 and Rawhide/F14 = F13; (2) Removing KpackageKitSmartIcon.notfyrc solved the issue in F12.
Sorry for the noise :-)
Martin Kho
PackageKit develops very fast, that's great. But I get the impression that the developers/maintainers are not too good in communicating what they are doing/changing. This must be very frustrating for the kpackagekit developers/maintainers to keep up with these changes. I don't like to have gnome-PackageKit in KDE either. I miss programming capabilities, but if I had them I would create an alternative not depending on PackageKit. IMHO, a package manager is a very critical app. What about reviving the package manager that lived in kde 3?
Martin Kho
If we dont want to lose users to GNOME because of not fully working, suggesting stupid things KDE apps, we might better use the alternative, even if it's written GTK/GTK+. By the way, should everybody use the GNOME SPIN as well because there are no QT alternatives for the installed system-config-* utility's in the KDE SPIN? ;)
We actually do have alternatives for some of them, but the GTK+ app gets dragged in by Anaconda's dependencies. :-( For example, there is KUser in kdeadmin which can be used instead of system-config-users. This Anaconda dependency bloat is one of the unsolved problems. Others are stuff I use once and never again (e.g. system-config-selinux, to turn the crap off and never look at it again). It's not the same as a package updater which users will be running daily.
Kevin Kofler
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On Sat, Mar 20, 2010 at 6:16 AM, Kevin Kofler kevin.kofler@chello.at wrote:
Thomas Janssen wrote:
Since i was the one who suggested it.. :) I do understand you but, if the KDE alternative is just giving a very basic functionality and is having problems (VPN IIRC) then we should consider using what works well, gives more output, does not suggest (again at the beginning of an update to reboot) stupid things.
Uh, VPN problems are a NM/KNM issue, not a KPK one.
Whoops, i mixed a NetworkManager issue in here, sorry :)
The "suggests a reboot too early" bug is bizarre indeed, I should look if I can silence those reboot prompts. (I'm for silencing them entirely, KDE users are smart enough to know when they need to restart their computer. ;-) It'd also probably be the fastest way to zap that bug once and for all.)
Another thing I noticed is that KPK doesn't recognize different update types anymore after the latest PK update. :-(
I think what needs to happen here is that more people need to test PK updates in testing and that those updates need to be BLOCKED from getting pushed to stable if they break KPK. Throwing out KPK is entirely the wrong solution for such regressions introduced by PK updates. (Neither of the above bugs happened before the latest PK update. It's not KPK's fault that PK breaks backwards compatibility under it.)
One problem is that PK/KPK (and GPK, too) moves so fast that, even when I'm running the latest Fedora release, I'm still always running an already deprecated branch, so spending time fixing things might not pay off. (But on the other hand, F12 still has 9 months or so to live, so I guess fixing F12 issues is beneficial in any case.)
I feel sorry there. I know you have already a lot of work and you do a great job. I badly need to learn to code to be able to help out a bit more.
KPK is in my eyes, ugly, unreliable and too basic. I suggested to you as well to try the latest GNOME-packagekit to see what i mean. I think KPK is on it's way, but not yet ready.
Yet KPK just works. (Neither of the above 2 bugs is a showstopper, they're just minor annoyances that can be easily worked around.)
Well, yeah, it "just" works. It would be good if that two annoyances are fixed. I know how hard it is sometimes, for various reasons. And yes, it needs moar testing. I will help out more with testing it, even i'm a yum updater ;)
If we dont want to lose users to GNOME because of not fully working, suggesting stupid things KDE apps, we might better use the alternative, even if it's written GTK/GTK+. By the way, should everybody use the GNOME SPIN as well because there are no QT alternatives for the installed system-config-* utility's in the KDE SPIN? ;)
We actually do have alternatives for some of them, but the GTK+ app gets dragged in by Anaconda's dependencies. :-( For example, there is KUser in kdeadmin which can be used instead of system-config-users. This Anaconda dependency bloat is one of the unsolved problems. Others are stuff I use once and never again (e.g. system-config-selinux, to turn the crap off and never look at it again). It's not the same as a package updater which users will be running daily.
Indeed, that makes it hard to have alternatives installed with the livecd as we have still the good-old-700MB ones. But to be honest, i don`t care that much what is used for that system-config-* stuff. Same here, i use them once in a while. Most times if i use one of them, just because i'm curious about changes or if a user reports a problem with it ;)
On Wednesday 17 March 2010 19:54:56 dexter wrote:
On 16 March 2010 16:55, Rex Dieter <> wrote:
We've got a draft of what we're considering as the target audience for what the fedora kde-sig produces.
https://fedoraproject.org/wiki/SIGs/KDE/KDE_Target_Audience
Comments?
This Project now has an identity crisis. I've read this and the boards target audience & both don't change a single thing which doesn't happen already or is all this about writing down current policy? I don't get it.
You also asked what I want from a kde (linux) distro:
- Polish, no ui bugs in your face
- Integration, kde apps/front-ends/services by default (an issue only
in gnome shops)
- Community, users supporting users
- Developers, developing the latest & greatest
Add to that list * Optional access to state-of-the-art/possibly-unstable packages for testing
and I think that about covers it ;-) since that's exactly what we do have now.
Anne