RFC: Moving RSIBreak to KDEUtils?

Aaron J. Seigo aseigo at kde.org
Sat Jul 25 07:13:24 BST 2009


On Friday 24 July 2009, Tom Albers wrote:
> Op Friday 24 July 2009 03:57 schreef u:
> > > > no; release management really ought to be extended to extragear, but
> > > > that's been only half-way managed properly at this point.
> > >
> > > Anyone can tell why?
>
> It's not half-way managed. There just is no need for it, except for 1 or 2
> apps. Most of the apps that get packaged see hardly any development. I
> rather decided to not create tarballs anymore at each release. Simplifies
> stuff.

well, we're going to eventually end up with the same problem we faced in the 
past: apps asking to be part of the core set of apps simply so the author can 
avoid release management.

> > > > but if the issue is
> > > > release management, then we'll end up with hundreds of apps in the
> > > > main modules and there will be simply no way to communicate "these
> > > > are the core applications we recommend for basic functionality
> > > > expected from a desktop computer for <category>".
>
> Reality is that every distro makes his own mind what to put in their meta
> packages. All resulting binaries end up in separete packages. So you can
> reach the same goal by making a techbase page describing what apps you
> think are best.

i'd be interested in hearing what packagers would think of a wiki page 
approach.

from the upstream side of it, it just sounds like one more piece of 
documentation that risks becoming outdated. currently these recommendations 
are self-documenting and there is no extra work needed.

> Reality again is that users install the apps that they
> need, I don't think many exclusively rely on meta packages.

virtually every single person who "installs Linux" and uses KDE gets this by 
virtue of the default install for their distro. for modules that aren't part 
of the default install (e.g. kdesdk, as you note) you are probably right.

> > > And until there are really "hundred of apps" in extragear I cannot
> > > follow you. Especially for a category as broad as Utility.
> >
> > yes, there are "only" a little under 50 apps in there right now. it'd be
> > great to see it grow a lot bigger .... there are many KDE applications
> > out there that would be great to bring in closer to the rest of the "KDE
> > Universe", but to do that we need to have a system that's ready for such
> > a thing.
>
> You have to rethink this bit in the current time. In the past one of the
> key advantages was having a central svn repository. With git around the
> corner and hosters like gitorious and github, the need for this hosting
> within KDE is gone.

i think the loss of continuity across our community by splintering the 
repository and landing the results all over the place is something we really 
ought to try and avoid happening when we move to git. if we don't, many apps 
will become far less visible than they currently are.

the worst thing that could happen in a move to a DVCS is that we splinter our 
large development community into separate smaller ones that don't have as much 
cross-talk between them. sharing common tools is a big part of that.

> Mail notification, user management, etc, all there (or
> will be soon). You need to wonder why any project would like to join our
> project. 

visibility to other developers, translators and users.

> So yes, I'm a fan of moving stuff to the main modules, or moving the apps
> out of the main module all to extragear

that's certainly a possibility. it does mean that we then have no mechanism to 
recommend a default set of applications to downstream and make it a lot more 
difficult for people building their own KDE from source.

it would also probably mean the end of coordinated releases, unless we cherry 
pick from apps in extragear and release those every 6 months in which case one 
has to ask what the benefit is there over just having a set of core modules.

> > i really don't want to see plasma components spread all over our svn
> > unless they are really tightly bound to a given application (such as some
> > of the kde edu ones) as it would make it far more difficult to manage
> > them for the plasma team and from the user perspective they are all "just
> > widgets".
>
> I think the opposite. You will soon have a hundreds of widgets and deviding
> them in categories makes all sense in the world. And hey, we have the
> categories already...

if we want to organize them, we can do so within the one module. no need to 
split it up into multiple modules.

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

KDE core developer sponsored by Qt Software
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090725/653143fb/attachment.sig>


More information about the kde-core-devel mailing list