Quality checks (again)

[Aaron J. Seigo]

On Monday 20 March 2006 09:04, Thiago Macieira wrote:
> Andras Mantia wrote:
> >Maybe call ported to Qt/KDE4. Means that all the code is completely
> >ported to Qt/KDE4, without using Qt3Support or KDE3Support classes.
> >Valid for both applications and libraries.
>
> I don't agree. It should apply only to the core libraries.

ask

> > 3. Regression test suite exists
> >Automatic tests (previously make test) are written.
> >Valid for libraries, might be useful for some kind of applications (eg.
> >those having a parser).
>
> 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.

IMO it should be encouraged and for new classes in kdelibs perhaps even 
enforced. while it is difficult to back after the fact and write the tests 
(though we certainly can with enough time and determination) there is no 
reason for new classes to enter kdelibs w/out unit testing. 

bottom line is that if we simply say "it can't be done" then we're right, but 
if we say "we can get coverage for <insert parameters>" then we're also 
right ;)

> > 7. KIOSK aware (merge with 6?)
> >The settings of your applications can be locked down with the help of
> >KIOSK methods ([$i] in the config file). Means that if the global
> >config file (or in a config file from a profile matching the user) has
> >an entry with [$i] after it, the setting cannot be changed by the user,
> >and if he/she changes in the local config file, it will be ignored.
> >Valid for applications.
>
> Again, valid for libraries too. But I don't think it should be merged:
> making settings documented and using KXConfig and preparing a KIOSK mode
> are two completely different use-cases. The configuration locking is done
> at the KConfig-level or deeper (backend). There's nothing the application
> author needs to do to enable it.

not quite. as waldo noted, you may need to check for action-restrictions. the 
application may also need to take special care, for instance kicker checks 
for immutability of groups when showing certain context menus or allowing 
buttons to be moved/removed.

additionally, there is the issue of supply absolute path names to KConfig as 
opposed to using the filename+resource type. this short-circuits the 
configuration cascading and therefore circumvents kiosk settings.

> 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. A very simple example

there are a few exceptions (e.g. konsole) but those are the exceptions, 
certainly not the rule.

> I think this could be an "extra item": applications that do intend to be
> used in a KIOSK environment would get a "KIOSK-certified"

that'd be useful indeed =)

> This is also the checklist that should be applied for promotion from
> kdereview to extragear. (playground-to-kdereview promotion should happen
> on author request)
>
> We should also instate a policy of demoting from extragear to kdereview,
> somehow.

and eventually from KDE releases to extragear or extragear to kde releases as 
well?

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- 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/2d29a834/attachment.sig>