New authorization library moved to kdereview

[Matthew Woehlke]

Nicola Gigante wrote:
> Il giorno 17/lug/09, alle ore 22:30, Matthew Woehlke ha scritto:
>> If it is qt-only, and you have no current plans of using KDE 
>> libraries, kdesupport (or even an independent repo) might be better 
>> since that could better encourage use by qt-only applications as well 
>> as KDE.
>>
>> Just a thought...
> 
> It doesn't have to remain qt-only. It just doesn't need kdelibs at the 
> moment.

If it goes into kdesupport, it /will/ need to remain qt-only. So if you 
know you are going to be using kdelibs bits in the future, then the 
decision is easier :-).

OTOH that means qt-only apps can't use it. That may not be a big deal, 
just something to keep in mind.

Another thing to ask is if you want to release with kdelibs or not. This 
may be an interesting question, since if you don't want to tie into the 
core KDE release schedule, you'll have to go the kdesupport route, but 
then you can't use kdelibs. (At least currently, we don't have anything 
that needs kdelibs and is needed by kdebase that has an independent 
release schedule.)

> Do you think kdesupport is a right place? Would the inclusion in kdelibs 
> make a wide adoption easier?

For what it's worth, I don't think being in kdesupport would make 
adoption any more difficult compared to being in kdelibs. Consider that 
you have important bits of KDE such as strigi, phonon and akonadi in 
kdesupport.

I think the question is best answered based on:
- Will it require kdelibs, or remain qt-only? (Maybe part of it will 
live in kdesupport and be qt-only, and part will live in kdelibs?) Do 
you want it to be usable by qt-only applications?
- Do you specifically want, or not want, to be tied in with core KDE's 
release schedule?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
  ,= ,-_-. =.    Function
((_/)o o(\_))  Flexibility
  `-'(. .)`-'  Freedom
      \_/     The Power of GNU