Quality checks (again)

[Andras Mantia]

On Monday 20 March 2006 18:04, Thiago Macieira wrote:
> I see no problem in applications using to KDE3Support classes or
> Qt3Support classes or methods. It should be a goal to clean that up
> for a future release, though. We at Trolltech put a lot of effort
> into Qt3Support to make it useable for more than just a "mandatory
> step" in porting to Qt4: it's supposed to be useable and used.

I don't know. I would certainly like to see that applications in the KDE 
repository are completely ported and do not use support libraries when 
KDE 4.0 is released. Well, for applications we might include another 
item "does not use Qt/KDE3 support libraries".

> What is important is that the public API does not expose deprecated
> methods/classes from KDE3 and Qt3.

Yes, this is certainly the biggest issue.

> > 3. Regression test suite exists
> This is very difficult to judge. A basic test suite should be
> required for all classes, but given our difficulty in finding
> maintainers for our existing classes, it'll be even more difficult to
> find people to write testcases. Not to mention a comprehensive one.

The checks have two purpose:
- to provide good code quality 
- to know the status of the porting and the repository

This means that not having some of the check items completed (like this 
one) will not mean we cannot release the library or application, but 
indicates a place where we should work on. Of course there are 
mandatory items, as an application not ported to Qt4 will not be 
released. ;-)

> Of course, this only applies for URLs. Once you obtain a local path
> for the file (if one can be obtained), using QFile is acceptable.

Of course. It's not that all QFile calls should be converted, just that 
if it makes sense for an application to work with URLs instead of file 
paths, do it and don't restrict its usage.

> > 6. Uses KConfigXT

> Valid for libraries that load settings too.

I was thinking about this, but as I didn't remember any such library, I 
did not list it. Basicly many checks are valid on a case by case basis.
> > 7. KIOSK aware (merge with 6?)

> Besides, I'm not sure if this is a point at all. Some applications
> are not supposed to be used in KIOSK-mode at all. 

I would like to know which one is not intended to be used in such mode.
Not being KIOSK aware should be the exception and decided after a 
discussion instead of making KIOSK awareness optional.

> > 8. Uptodate handbook
> >There is a handbook for your application and it is valid for the
> > current version (screenshots are uptodate, all functions are
> > described, there is no reference to menu items that do not exist
> > anymore and so on). Valid for applications.
>
> Questions: How about KParts? Since KParts can add items to the UI,
> where does that documentation go?

Right, KParts are something between a library and an application. Maybe 
more an application. My suggestion is to document the KPart in the main 
application that uses it. PDF part in KPDF (oKular), katepart in Kate, 
and so on. I don't know if there are KParts that do not have such a 
main application or not.
Of course if it is possible to create documentation for Kpart and link 
them to every application using them would be the best.

> > 9. Uses .ui files

> And KParts.

Right.

> This is also the checklist that should be applied for promotion from
> kdereview to extragear. (playground-to-kdereview promotion should
> happen on author request)

Good idea.

> We should also instate a policy of demoting from extragear to
> kdereview, somehow.

Unmaintained code might be a good policy. Failing to comply for the 
above items might be another one. After all if there is a checklist for 
promotion, the same checklist might be applied to the applications 
already in extragear.

The current list is for 4.0. After 4.0 we might decided what items we 
keep and how often they are checked.

Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060320/bb9e4be5/attachment.sig>