Updating our tools

Luigi Toscano luigi.toscano at tiscali.it
Sun Aug 9 15:56:04 BST 2015

Michael Pyne ha scritto:
> On Sun, August 9, 2015 09:58:26 Allen Winter wrote:
>> On Sunday, August 09, 2015 09:35:06 PM Ben Cooksley wrote:
>>> On Sun, Aug 9, 2015 at 3:15 AM, Allen Winter <winter at kde.org> wrote:
>>>> On Saturday, August 08, 2015 04:59:49 PM Elvis Angelaccio wrote:
>>>>> Sorry to bump this old thread, but it looks like Krazy still complains
>>>>> about kdelibs4 errors even if an application is now KF5 based.
>>>>> For instance consider again Kanagram:
>>>>> http://ebn.kde.org/krazy/reports/kde-4.x/kdeedu/kanagram/index.html
>>>>> Am I missing something? Is there another page showing KF5-related
>>>>> issues
>>>>> for KF5-ready apps?
>>>> If Krazy is running in the kde-4.x component, then it does use the KDE4
>>>> checkers.
>>>> For now, Krazy only knows its looking at KF5 code if it's running in the
>>>> frameworks 5 component in
>>>> http://ebn.kde.org/krazy/index.php?component=frameworks&module=framewor
>>>> ks5
>>>> I don't see kanagram listed in the frameworks5 component.
>>>> The KDE projects also lists kanagram in kde-4.x only, as far as I can
>>>> tell.
>>>> So first step is to get kanagram listed as a frameworks project.
>>> To my knowledge there isn't anything on projects.kde.org which states
>>> a project is kde-4.x only. Where is this information coming from?
>> the projects db
>> I see that kanagram master is kf5 based but is not part of frameworks.
>> therefore I will need to invent a way to detect that a project is kf5 based.
>> do we have an easy way to detect kde4 vs. kf5 projects?
> The only way I'm aware of is to use the kde-build-metadata/logical-module-
> structure metadata (this is used by kdesrc-build and the CI). This is much 
> more annoying than a simple lookup but there are at least a couple of tools in 
> kde-build-metadata that can be used to help.
> I believe i18n tracks the 'unstable' and 'stable' branches for each module and 
> 'unstable' might mean "KF5" by now. This information *is* available with the 
> project data directly. But maybe Albert or Luigi could better explain how the 
> i18n infra is setup and what we can conclude from these variables.

We track four branches (information available from kde_projects.xml):

We don't use them directly, but we keep our metadata in sync with them. Yes,
that could be done in better way; but we can't consume the information
directly from projects.k.o because a wrong/outdated information leads to
wrongly tracked messages (and maintainer sometime forget to update them).


More information about the kde-core-devel mailing list