[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Move KSirc to extragear
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2007-01-24 19:57:09
Message-ID: 200701241257.10781.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 24 January 2007 7:31, Jaison Lee wrote:
> > the vast, vast majority of people don't give a flying monkey about irc.
>
> ...
>
> >... that 1-2% of our users use.
>
> How can you possibly justify these statements? You have no data, no
> statistics, no metrics at all except for Aaron's Personal View Of the
> World. :) 

then i suppose you missed my other email in this thread where i provided some 
numbers regarding irc use in the last week versus the number of MSN users in 
Holland (spoiler: in 2002 there were 4x as many MSN users in Holland than 
there were people on irc this week; 26x as many in all of Europe. that was 4+ 
years ago and just one of the major networks.)

> > let's put it this way: what would you feel about a desktop with lots of
> > gadgets for people who were really, really into marine crustaceans? to
> > the point where your interests were hidden and marginalized?
>
> This borders on reducto ad absurdum.

in my defense, i tried reasoned explanations first.

> We're not talking about IRC 
> gadgets all over, we're talking about an application here.

this is little more than semantics.

> we've gone beyond KSirc at this point.) If you are asking how I would
> feel if KDE decided to include an application (presumably in kdeedu)
> about marine crustaceans, the answer is I would love it!

don't get me wrong, i think such an app would be awesome too. where you and i 
differ apparently is that you consider trunk/KDE/kdeedu to be the best home 
for it while i feel that trunk/extragear/edu would be a better place for it.

what this really comes down to is the scope of extragear. i see it rising in 
importance given that it is the home for such apps as k3b, amarok, 
konversation, digikam, kaffeine, ktorrent, kile, kst, kiosktool ..... it's 
proving itself to be a great way to incubate and distribute applications that 
appeal to limited yet significant groups of users as well as applications 
that have broad appeal.

in turn this begs the question: what is the purpose and scope of the "KDE 
modules". as the overlap between KEG and KDE modules grows and apps in KEG 
continue to eclipse other apps both in and outside of KDE, i think this is a 
very apropos question. what i'm suggesting, based mostly on conversations 
i've had with others (IOW, these aren't my thoughts alone or even originally; 
i first discussed this with Waldo in 2004 in fact), is that KDE modules 
should be defined in a way that provides a meaningful distinction from our 
KEG apps. KEG both alleviates pressure from KDE modules (e.g. having to 
provide a home for -every- KDE app) and has grown some amazing apps in its 
own right; in turn KDE modules should perhaps be careful not to artificially 
tilt things in favour of one app or another, not confuse our users as to 
their purpose and help support the success of KEG in the process.

> I think it 
> would increase KDE's visibility to a new set of users, and maybe I'll
> learn something about marine crustaceans along the way. I think we are
> losing this aspect with the current mindset of removal. In fact,

it's not *re*moval, it's just moving it. as our software catalog grows it's 
simply not realistic to expect people (be they OSVs or end users) to want to 
have every app written with KDE on their computer. the answer is to provide a 
store from which people can shop (can't beat the prices! ;) for what they 
want. this is the role i'd personally like to see KEG take on.

we also know that we need to provide a complete-enough experience "out of the 
box". this is the role i'd personally like to see KDE modules provide.

> KStars falls into EXACTLY this category and I don't see anyone
> bickering for its removal, despite the fact that it is an ungodly huge
> chunk of code.

it's not about size. it's about the educational software collection: astronomy 
is, in that scope, a huge area of endeavor and interest.

> If only programs that are used by a majority of people are to be in
> kde modules than how many are going to be left?

fewer than we have now. all the apps will remain available, however. it's 
about sensible defaults.

> What happens to kcharselect and khexedit?

a character picker is a critical utility for what should be obvious reasons.
in the scope of a developer's toolkit, a hex editor is similarly critical.

> What about Kjots since BasKet exists?

i don't see an issue here. basket and kjots are rather different in that kjots 
provides a straight forward and elegant note taking utility (very common 
need) while basket is a "full on" information collection and management app 
for individuals.

if people didn't take notes, i'd be more concerned about kjots. but not taking 
is a common practice and so we provide an elegant tool to do that. info 
collecting fiends might prefer basket. i wish basket was in KEG, actually, 
for this reason.

> Most  programs have an alternative out there.

it's not solely about alternatives, though that factors in.

> How come an IRC client doesn't 
> make the cut but a DICT client and an LIRC program does?

dict client: because looking up the meaning of a word is common and DICT is 
designed to do just that.
lirc program: because without that you can't (easily) use IR hardware.

irc program: exhibits none of the above attributes.

> Who gets to 
> make these decisions and for what reasons and under what scrutiny?

very good question! primarily, the maintainer for the module. many of our 
modules don't have maintainers, however. the check-and-balance for module 
maintainers is the group of people who work on KDE's centre (KDE libs, KDE 
workspace and KDE default apps). input from the user (OSV and end user) 
communities is also influential. it needs to align with the application 
maintainer's wishes as well, of course.

i'm really hoping that as the TWG reconstitutes itself we'll have a smoother 
and better defined process for these things.

> Perhaps most importantly: If the kde modules are now handled on an
> app-by-app basis by all the major distros anyway, what possible
> difference does it make what's in them?

they let us define the expectations for a basic KDE installation; with things 
like kdeedu and kdesdk it gives us the ability to do the same for specific, 
vertical markets such as education and software development. 

unfortunately, right now we're screwing up in this effort by including apps 
that are highly irrelevant to a basic desktop.

the reason for this is historical: at one time the KDE modules were, quite 
literally, all the apps available for KDE. it made all the sense in the world 
given the state of the KDE world at that point to put all the apps in one 
place. we've grown since then =)

> If we want to identify and narrow down a core set of apps for a "basic
> user" (whatever that is) why don't we use kdebase for that?

because that would fail people who are interested in education but not 
software development, so we'd end up with kdebase/edu, 
kdebase/software-devel, etc... in other words, we'd reinvent the modules we 
have now only one level of hierarchy deeper (KDE/kdebase/ versus just KDE/). 
this would skirt the issues surrounding scope definition rather than address 
them in any meaningful way.

btw, it's not a "basic user" it's a "basic desktop". this isn't about 
profiling a specific basic user, it's about trying to profile basic desktop 
computer use and expectations taking into consideration things such as 
hardware enablement, common modern expectations (e.g. IM, email), etc.

this means we have a scope larger than the basic Windows desktop but smaller 
than the set of all possible apps.

> That means 
> move Kopete and KCalc and whatever default video and audio player we
> decide on into kdebase and that module becomes "The KDE". Then the
> other modules just become "extragear with the benefit of codebase-wide
> changes and a release schedule." That means kedit can come back to
> kdeutils (after its refactor of course) and I think a lot of people
> will be very happy with this arrangement. This seems like a far better
> plan to me than the one we're on.

"rearranging the deck chairs" is the phrase that comes to mind with this 
approach. here's what i've seen KDE moving towards over time (regardless of 
what i personally think about it, pro or con, btw =):

kdesupport -> home grown libraries that have a larger scope than kde
kdelibs -> libraries used for general development of applications
kde*libs -> libraries with a more vertical set of applications than kdelibs

kdebase -> the support tools (runtime/), workspace and essential apps relied 
on by other apps (e.g. file manager, help center, control center, etc)

kde* -> application sets with a common focus (e.g. networking, groupware, 
education, software devel, etc) that provide a reasonable starter set of apps 
that have broad audience appeal (e.g. astronomy for edu). people should be 
able to get common tasks done with these apps but will certainly be able to 
find gaps that map to various niches. (btw, this is why i feel we need to 
keep something like juk in kdemm even with amarok in keg)

extragear/* -> the universe of possibilities grouped by focus categories 
similar to kde* above. here is where niche needs are met, ambitious (in the 
sense of above and beyond basic requirements) efforts live and those who 
desire more autonomy find the space they desire.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]