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

Matthias Welwarsky kde-policies@mail.kde.org
Wed, 18 Dec 2002 12:43:41 +0100


--Boundary-02=_x9FA+dQLtwTLJ+M
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

Hi,

Some ideas on when Appls should be put into KDE CVS:

Definition: KDE CVS is the "core" modules kdelibs, kdebase, kdeadmin,=20
kdeutils, kdenetwork, kdegraphics, kdepim, kdemultimedia, kdegames.
Please add to this list if I forgot some important module.

kdeextragear is omitted deliberatly because it has its own policy, kdenonbe=
ta=20
because it's not released, translated or otherwise published.

The numbers are not to denote  a priority, only to address the rules easier

Basically there's one idea: The application must be worth the work it causes

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 technical=
ly=20
possible to translate it. This includes documentation.
4) It should "fit nicely" into KDE, meaning look&feel, use of KDE core=20
techniques (ioslaves, parts etc) where applicable.
5) It must be maintained and development progress and process must be visib=
le,=20
i.e. it should be actively developed using the KDE CVS.
6) there must be a team of developers working actively on the application.=
=20
There need not be a dedicated maintainer.
7) developers must be willing to accept the dictate of the KDE release cycle

Rationale:
1) is pretty obvious
2) If there's no benefit for KDE, inclusion would be bloat and must be avoi=
ded
3) obvious?
4) Every application in the CVS will sooner or later be reference for=20
development of other applications, if only because of non-availability of=20
comprehensive documentation.
5) peer review only works if development process is open.
6) having a team of developers makes it less probable for an application to=
=20
rot away silently once the original author looses interest. Having no=20
maintainer is usually not a loss. Basically, we only cry for a maintainer i=
f=20
an application is not developed any more and starts to cause problems.
7) obvious?

comments, additions, flames?

regards,
	matze


=2D-=20
Matthias Welwarsky
=46achschaft Informatik FH Darmstadt
Email: matze@stud.fbi.fh-darmstadt.de

"all software sucks equally, but some software is more equal"

--Boundary-02=_x9FA+dQLtwTLJ+M
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+AF9xANO+fpRuZ2IRArZ4AJ9PZwIjbhtVNGMBXLnPrbs3qdQkCwCgiIeX
v2ZafEdeW2rn3UdyWmXJSmo=
=d3uK
-----END PGP SIGNATURE-----

--Boundary-02=_x9FA+dQLtwTLJ+M--