----- Original Message -----
>
>
>
>
> ----- Original Message -----
> > From: "Adam Williamson" <awilliam(a)redhat.com>
> > To: "Discussions about development for the Fedora desktop"
> > <desktop(a)lists.fedoraproject.org>
> > Sent: Wednesday, March 5, 2014 3:20:06 AM
> > Subject: Re: KDE integration/status for Workstation
> >
> > On Tue, 2014-03-04 at 19:59 -0500, Josh Boyer wrote:
> > > Hi All,
> > >
> > > During the default DE discussions, a number of WG members expressed
> > > interest in keeping KDE as a release blocking DE for Workstation. QA
> > > is now asking FESCo about KDE's status as well in
> > > https://fedorahosted.org/fesco/ticket/1243
> > >
> > > So if KDE is going to be a release blocking DE for Workstation, we
> > > need to figure out how exactly it gets installed and what manner it
> > > would be tested in. In the above ticket I came up with the following:
> > >
> > > install the Workstation live image, install KDE through
> > > software-installer (if necessary), log into KDE from GDM after
> > > install, test
> > >
> > > However, that was entirely off the top of my head. Would the live
> > > image be large enough to contain the KDE Workstation already or would
> > > a user/QA tester need to install it through the software-installer?
> > > What tests should be done? Etc.
> > >
> > > Thoughts?
> >
> > This with my Personal Opinion hat on, not representing QA:
> >
> > I'm not sure all/most people who actually want to use Fedora KDE are
> > likely to be sold on doing it by downloading what they will see as
> > 'GNOME', installing that, and then installing KDE on top of it. I think
> > this will be fine for some folks, but there'll be a significant
> > constituency which just wants a KDE image.
> >
> > In fact we might be creating a bit of a problem, because I can see both
> > "want KDE as an alternative desktop on top of the Workstation product"
> > and "just want Fedora KDE" as two entirely legitimate and viable
> > constituencies, which sort of means we've just created a bunch of extra
> > work for ourselves. I'm not sure I see a clever magical solution to
> > that, though. Engage brain cells...
> > --
> Well my take is that there will never be a solution that makes everyone
> happy,
> but in my mind the expectation here has always been that the people who would
> not be happy about the proposed solution would end up focusing their energy
> on
> doing a remix. Because there isn't really a way we can make a product and at
> the
> same time be a solution for people who essentially want a different product.
Yep, and that probably leads back to the question if we want or don't want to
provide more products than we currently have so far (three). And to be honest,
I like idea having more products but with very high bar (that should apply
for all products) - to avoid a situation of having dozens of products but
still be inclusive.
There was FESCo ticket https://fedorahosted.org/fesco/ticket/1197 - it's now
closed with resolution: "AGREED: Close for now until the current products are
released at least once and/or anyone proposes a new product" and it's states
that the bar should be relatively high too.
KDE would be a great example of such first product - pretty strong KDE SIG
team, that consists of a few very active community members and Red Hatters,
proved to be able to solve release blockers (and pretty tough release blockers),
with quite a big user base and last few years known as one of the best and
most polished KDE experience (from distribution POV).
Steps
1. establish formal KDE WG from the initial KDE SIG members
2. create formal PRD
3. create Technical Specifications (based on WS Tech Specs or future Base
Tech Specs)
4. show commitment, provide resources for other teams - QA (test cases,
test days, help with release matrix coverage), marketing etc.
5. get approved - does not have to be for F21, start line would be pretty
late but do not block it, if KDE WG would be able to make it
6. profit!
For the idea of having for example Scientific products based on KDE - I don't
like it as these topic specific spin like things should be desktop agnostic
and really done on top of existing desktops in Software Installer (GNOME, KDE
whatever). And create spins/formulas whatever only when it's really needed
(but then it would be more remix).
One another thought - it could serve as a place for desktops that would not
fulfil WS WG requirements but could fulfil KDE WG requirements (there are
a lot of new Qt/KDE based desktops appearing recently)...
CC'ing KDE mailing list. Due to some other stuff, I'm not very active
recently in discussion but initially KDE SIG was more inclined to own
product, then I saw a few people more inclined being part of WS WG and
now I think it's clearly steering back to spin/product. Remix would be
suicide - even KDE SIG is pretty big team, active, with healthy
community, it would mean a lot of duplication etc.
Jaroslav
> Christian
>
> --
> desktop mailing list
> desktop(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/desktop
Since Fedora 18, all people speaking non English languages are
experiencing troubles in setting their system language without having to
manually install kde-l10n-* package. This is a problem for new
Fedora/Linux users.
I opened a bugreport years ago about system-config-language but the only
thing that changed, is that system-config-language is no longer present
in Fedora 20 KDE Spin, and even if you install it, it will not have any
effect on the system.
https://bugzilla.redhat.com/show_bug.cgi?id=830563
A new tool for installing system languages is an urgent need.
Hi,
we've prepared testing builds of kde-plasma-nm including libnm-qt and libmm-qt libraries in COPR repository [1]. The testing version includes a new design and few bugfixes and it is almost ready for stable release, we are just polishing its design. If you want to try it, just add the COPR repository and run update of kde-plasma-nm together with libnm-qt and libmm-qt and you also need to update NetworkManager from updates-testing repository (currently there is NetworkManager-0.9.9.0-29.git20140131.fc20).
Positive or negative feedback is welcomed. Thanks.
[1] http://copr.fedoraproject.org/coprs/jgrulich/plasma-nm/
Cheers,
Jan
--
Jan Grulich
Red Hat Czech, s.r.o
jgrulich(a)redhat.com