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

Eva Brucherseifer kde-policies@mail.kde.org
Thu, 19 Dec 2002 11:24:09 +0100


--Boundary-00=_J5ZA+d+Gip4sR0G
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Description: clearsigned data
Content-Disposition: inline

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


> 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.


This reminds me of the coding style document we started during the KDE e.V. 
meeting in Hamburg. The document was based on 
http://www.kde.org/whatiskde/devmodel.html 
the KDE Manifesto
http://www.kde.org/kde-manifesto.html
and some other document by Aaron which I don't have a link to.

Greetings,
eva
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+AZ5JTaAgihPikKQRAsTAAJ9ag8G1VcoC0/wI6Ybzfg3KXl3y/wCfQ/ww
1JO00J8J6iA7tCtx3ynPnYg=
=NGpQ
-----END PGP SIGNATURE-----

--Boundary-00=_J5ZA+d+Gip4sR0G
Content-Type: text/html;
  charset="iso-8859-15";
  name="CodeDesign2.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="CodeDesign2.html"

<html>
<head>
<title>KDE Software Design Principles</title>
</head>
<body>
<h2>THIS IS A DRAFT; IT IS NOT INTENDED TO BE RE-DISTRIBUTED IN ANY WAY</h2>
<h1>KDE Software Design Principles</h1>
<p>The KDE Project aims to achieve the following software design principles when developing its software.</p>

<ol>

<li>
<p>We keep our APIs stable for the benefit of developers who build their applications on the KDE platform.
</p>
<p>The Project realises that the support of applications built using the KDE libraries is essential to the continuing development of KDE and is happy for them to be used for this purpose.</p>
</li>

<li>
<p>We document our interfaces, file formats and application functionality.</p>
</li>

<li>
<p>We favour open, extensible and standardized document formats.</p>
</li>

<li>
<p>We strive for consistency and usability in our software.</p>
</li>

<li>
<p>We target open operating systems and encourage ports to other platforms.</p>
</li>

<li>
<p>We write maintainable code. When we have to do clever things we document it, so others can understand them as well.</p>
<p>It is essential to write code which is extendable, sufficiently well commented to enable a high level of understanding, and to avoid quick "hacks" which appear useful initially but later cause significant problems.</p>
</li>

<li>
<p>We start with reasonable functionality and configurability in our applications and improve iteratively over time.</p>
<p>Software development is a process which takes time and should not be rushed.</p>
</li>

<li>
<p>We only add features when consistent with our design principle.</p>
<p>Feature bloat is a problem that can easily affect any software, and we avoid it by ensuring that features added are important to a sufficiently large group of people.</p>
</li>

<li>
<p>We test our software before release.</p>
<p>Testing is critical to ensure that the software works as intended and expected to ensure that the user experience is of a high quality.</p>
</li>

<li>
<p>We implement and maintain current technologies and a contemporary look and feel, and are open to innovation.</p>
</li>

<li>
<p>When we make suggestions we are willing to put in the work. ("We should ..." means "I will ...").</p>
</li>

<li>
<p>We support both our users and developer community, and welcome constructive feedback.</p>
</li>

<li>
<p>We write internationalized software and encourage localization.</p>
<p>We realise the importance of being applicable to local cultures.</p>
</li>

<li>
<p>We write stable software that provides the best possible security to our users.</p>
</li>

</body>
</html>

--Boundary-00=_J5ZA+d+Gip4sR0G--