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 <win...@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): stable/kdelibs4 trunk/kdelibs4 stable/kf5 trunk/kf5 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). Ciao -- Luigi
