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

List:       kde-i18n-doc
Subject:    Re: Re: Splitting kdebase?
From:       Park Shinjo <kde () peremen ! name>
Date:       2011-09-13 6:32:28
Message-ID: CADkcP6g6MtX1NVZZaQ+7FE=VARVtAMhgTeHiG7TgqjKADOTi7A () mail ! gmail ! com
[Download RAW message or body]

I was spending Chuseok holidays, so sorry for my late reply.

Following all the discussions, I agree with this criteria. But please
notify on the list about the change and teams doesn't meet new
criteria before actual change (maybe for 4.8).

2011/9/12 Albert Astals Cid <aacid@kde.org>:
> A Dissabte, 10 de setembre de 2011, Park Shinjo v� reu escriure:
>> Some question: if the templates/messages/kdebase is splitted, then how
>> release criteria will change? Current release criteria specifies kdebase to
>> be >=75%.
>
> That is a good question, had not though of it.
>
> Given that the "minimum" requirements for a KDE application to run is kdelibs
> + kde-runtime and that there is a focus to move to make KDE more useful as a
> platform and not only as an integrated destkop i am suggesting that we replace
> 75% of kdebase with 90% of kde-runtime which will be a smaller number of
> messages (can't give a final number but excluding kde-workspace and kde-
> baseapps from the total easily removes more than 5000 messages).
>
> What do you think?
>
> Albert
>
>>
>> I think kdebase is large enough, so voting for splitting.
>>
>> On 2011년 9월 9일 금요일 오후 11:43:09 Albert Astals Cid wrote:
>> > In templates/messages/ we have a kdebase folder that is actually a bit
>> > of a lie since there is no a kdebase repo anymore but three,
>> > kde-baseapps, kde- runtime and kde-workspace (with kate and konsole
>> > being child of one of those three).
>> >
>> > The question is that if you would prefer me splitting the kdebase folder
>> > into those three new naming conventions or you are happy enough with
>> > keeping only one folder.
>> >
>> > Personally i do not care :D
>> >
>> > Albert
>

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