Le 17/01/2015 00:00, Albert Astals Cid a écrit : > El Dilluns, 12 de gener de 2015, a les 23:58:26, Bruno Coudoin va escriure: >> Hi, >> >> We just made our first official release of GCompris. We now have the >> need to maintain a stable and a master version. This is not possible to >> do so in playground so it is time for us to go forward and move to >> extragear. To this end, we have just moved to kdereview. >> >> I have no idea what the review is looking at so I prepared nothing. If >> there something I can do let me know. > > Several people pointed you at > https://techbase.kde.org/Policies/Application_Lifecycle which contains a > paragraph tha says "there are some rules to follow before you are allowed to > move to either location:" > > We can be lax about some of them, but you should explain why you don't want > to > follow them.
Hi, I am sorry for my late answer, I completely forgot about it. I copy here the KDE requirements with the answer: - There should be user documentation in docbook format. If you need help, you can ask for help to the KDE Documentation team: kde-doc-engl...@kde.org. We have 2 types of user documentation: * inline, each activity has its own documentation easily accessible from the help menu in GCompris. This is used by children and teacher or parent to discover what to do in this activity. It is translated through po files. This proved to be adapted to GCompris use case and I believe we should keep it this way. * online manual (http://gcompris.net/wiki/Manual) which is orientated towards sys admins and advanced school usage (creating profiles, accessing children logs, ...). This should be moved to docbook. I added a task in our tracker for that: http://gcompris.net/wiki/Qt_Quick_Migration_status#Core - There should be developers documentation in the form of apidox for libraries you can check this at ebn This is something we have not yet investigated but as GCompris matures it will be more and more needed. The target here is to help activities developers. I added this need in our task tracker http://gcompris.net/wiki/Qt_Quick_Migration_status#Core - There should be no krazy code checker issues reported. Again, you can check that at ebn. There is also a tutorial on using Krazy available here on TechBase. We did work on that and fixed all the issues on the devel branch. By the way, EBN must be changed to run krazy with '--check-set qt5' and not kde4 as it is today. - If possible, there should have been a basic usability review of your application. Usability people are hard to get, so this is not crucial. We would be pleased to get help on that. This is a very important point for us that we take seriously. So far, as the application has been released on Android we had the chance to get some user feedback that we took in account. - You should have checked for basic problems with a profiler. I hope we will get a tutorial on how to do this soon I have already used valgrind on C++ projects but not tested what it brings to a QML project. We take performance seriously to avoid excluding schools with limited hardware to run GCompris. - Your application should be completely translatable. The translation process is in place and works as expected. We still have datasets for some activities that should be moved to the po system. > > As a side note, you don't ship a .desktop file, which basically makes your > app > invisible to desktop menus/launchers. True, it would be easy to pick the Gtk+ ones but I am not sure how to make them translatable. Bruno.
