Thoughts on when to put/remove applications to/from CVS

[Lauri Watts]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 18 December 2002 12:43, Matthias Welwarsky wrote:

> 1) The author must consent to the inclusion
> 2) KDE as a platform must benefit from the inclusion.
> 3) The application must be "worth" a translation, i.e. it must be
> technically possible to translate it. This includes documentation.
> 4) It should "fit nicely" into KDE, meaning look&feel, use of KDE core
> techniques (ioslaves, parts etc) where applicable.
> 5) It must be maintained and development progress and process must be
> visible, i.e. it should be actively developed using the KDE CVS.
> 6) there must be a team of developers working actively on the application.
> There need not be a dedicated maintainer.
> 7) developers must be willing to accept the dictate of the KDE release
> cycle

Ones I'd like to consider adding:

1: Passes a security check of the source, up to the standards that the rest of 
KDE has been/will be very soon.

2: Is, within reason, portable.  That is to say, doesn't have large parts of 
it's functionality #ifdef'ed out to avoid having to deal with non-Linux 
platforms, and doesn't use linux specific or gcc specific or glibc specific 
"isms", or at least is willing to let us (non-majority) users help fix them.  

3: The author understands that by putting their application in CVS, other 
people will commit directly to it, especially but not limited to Icons, 
Styleguide fixes to gui items (i.e., spelling errors and UI layout), 
documentation, the build system and i18n fixes.  

My justifications:
1: defeats the purpose of cleaning up KDE, if we are only to dirty the waters 
with a new application.  

2: There have been occasions when suggestions, patches, and just plain 
questions from FreeBSD developers have been reacted to with open hostility by 
developers of applications in KDE CVS.  So far they've all been sorted out, 
eventually, I'd like to avoid that continuing to happen.  I'll survive being 
told I'm a pain in the ass, I know it already, I won't have users being told 
that by self-righteous developers.

3.  There have been numerous times that things we've done for 
docs/proofreading/i18n have just been reverted, or committed over with an old 
version (which amounts to the same thing.)  

Sometimes it's because people don't realise that there's a whole lot of us 
working on the infrastructure type things like this, and a couple of times 
it's been followed by a "It's MY app, you should ask ME before you commit 
anything anywhere near it".   I don't think that works inside a large project 
CVS repository.  I can certainly see where a patch that changes functionality 
of an application should be reviewed by the maintainer if there is one, but I 
also don't think I should have to ask every single time I fix a spelling 
error in a document (or the GUI itself)

I'd love to add "has some documentation, no matter how bad, and even just a 
decent README would be a start" but there'll be pigs flying around my head 
while I am ice skating in hell before that would happen.

Regards,
- -- 
Lauri Watts
KDE Documentation: http://i18n.kde.org/doc/
KDE on FreeBSD: http://freebsd.kde.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE+AQ5U/gUyA7PWnacRAhCAAJ9JyjRJwBWE3cvbOs/o0A0sFbzzaQCdFzOV
p30EGtNnvlwtY3XYFkDmAW4=
=5/FY
-----END PGP SIGNATURE-----