[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-edu-devel
Subject:    Re: [kde-edu-devel] First Announcement Of KMathCenter
From:       Andy Fawcett <andy () athame ! co ! uk>
Date:       2002-04-30 16:17:24
[Download RAW message or body]

On Tuesday 30 April 2002 18:21, dominique devriese wrote:
> On Tue, Apr 30, 2002 at 12:37:57PM +0200, Christian Parpart wrote:
> > Well, KMathCenter *must* not go into HEAD for 3.1 (this really
> > would be nice) but I really can wait until 3.2. Nevertheless I
> > can't feel very funny about kdenonbeta since there is source code
> > wich mostly isn't able to be compiled well (IMHO). I'd rather wait
> > for 3.2 then putting it into kdenonbeta.
> >
> > Christian Parpat.
>
> Hi, about kdenonbeta:
> it _is_ very useful to have your app in kdenonbeta a while before
> inclusion in a release.  Kig (my app) has been there for a while, and
> I've had help from various people on getting it into shape for KDE:
> there are many things you prolly won't think of yourself:
> 1) docs (you should make them, and you should give people the
> opportunity to fix them (you're bound to do things wrong :)

Docs are quite difficult to get right, and the KDE project has some 
rather strict guidelines to follow. For instance, jokes in the docs is 
generally a bad idea, and we *always* attribute Trademarks referenced. 
Luckily, the docs team is easy to work with, and is very helpful.

It's not essential for apps in kdenonbeta to have docs, but if you do 
have some they should validate properly.

> 2) fixing Makefile.am's and such

Unless you're perfect, these will get changed, possibly to get the 
program to build on non-linux platforms.

> 3) some bugchecking

Very important.

> furthermore, KDE progs need to be translated, and the docs too.  This
> requires the translation teams to have your pot-files, and it is best
> to have your prog in kdenonbeta for a while for this, to allow them
> to work on it.

Well, the docs teams won't normally translate the documents until it 
goes into a main module, as they have plenty of other work to do. They 
might do it if they are bored.

You may find that people will help improve the compilability of your 
code when it is in kdenonbeta, as they try it with different compilers 
and operating systems.

Once the software moves into a main module (one of the ones KDE 
distributes), you'll find that people will make changes to all aspects, 
*whether you like it or not*. That's the nature of this way of software 
development, and it's something you need to be comfortable with. It's 
not a case of "giving people the opportunity", it's more that you have 
put your code/docs in a public repository that has over 700 people who 
*can* make changes to them. In the vast majority of cases, the change 
will be an improvement.


-- 
Andy Fawcett      |   "In an open world without walls and fences,
andy@athame.co.uk |      we wouldn't need Windows and Gates."
tap@lspace.org    |                              -- anon

_______________________________________________
kde-edu-devel mailing list
kde-edu-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-edu-devel
[prev in list] [next in list] [prev in thread] [next in thread]