[bt-devel] Integration into KDE (e.g. KDEEDU)

heiko.evermann at gmx.de heiko.evermann at gmx.de
Tue May 31 12:28:14 MST 2005


David,

> > For bibletime this would mean:
> > 1) KDE distributions would include bibletime, so bibletime would be
> > included in all major Linux distributions.
> > 2) The KDE translation teams would translate bibletime into a lot of
> > languages. e.g. for KStars we got the Swedish translation for free and we
> > got a nice reply from a Swedish father who told us that KStars was the
> > only free desktop planetarium available in Swedish and that his child
> > really liked it. The child knew Swedish, but no English.
>
> While greater publicity is a good thing I agree, but there are some
> problems with that, such as that making kde-edu dependent on the sword
> library. And I personally have some qualms about Bibletime being in the
> menu under Edutainment. But then again, the extra translations would also
> be beneficial. So, as I said, I think it should be discussed
If you do not like kdeedu, you could also propose a different kde group. But I 
think kdeedu would be the best. kdetoys would not be a better choice. The 
main focus on kdeedu is to provide teaching applications. And in a way 
bibletime fits very nicely there.

Concerning the dependency: KDE already depends on lots of other libraries. KDE 
distributions (from the hands of KDE) are a big bunch of source files. When 
you compile KDE from source, configure checks for the neccessary libraries 
and the neccessary minimum version. If the requirements are not met, you get 
a message like
> The library xy was not found on your system. This library is requred for 
KStars. KStars will not be compiled.
or 
> You need at least version 1.5.8 of sword library. bibletime will not be 
compiled
and everything is fine. Those people who make the binary distributions will 
provide suitable RPM-files and would in our case provide a sword-1.5.8.rpm 
and make the installation of kdeedu.rpm dependent on sword-1.5.8.
Or, if a Linux distro has religions reservations against providing a binary 
for bibletime, they could choose not to compile bibletime and then their 
kdeedu.rpm would not include bibletime.

> She has a point with this. Right now the only external libraries that
> determine the bibletime release schedule are the sword libraries. And
> keeping with them is really more important than kde. This has been one of
> the holdups with the release of 1.5, for instance. But what are the other
> rules that we may not want to follow? I personally like to have an idea of
> what I'm getting into with something like that before I do it.
>From what I experienced with kdeedu/kstars and with the translations of KDE 
into Esperanto and Low Saxon, the situation is like this:

* Development takes place in the "HEAD", that is the main branch of the source 
repository. (I think since they switched over from cvs to subversion, it is 
called "trunk" now. ) Here you can develop any way you please. It should 
compile. You can even extract your own personal source snapshots and publish 
them on bibletime.info.
* For a major release (e.g. KDE 3.4) at a certain point a branch is opened 
(e.g. KDE_3_4_BRANCH), that means within the source control system, a copy is 
made. This branch is then used for providing the maintenance releases KDE 
3.4.1, KDE 3.4.2 etc.
* There are restrictions on development in the branches. Only bug fixes are 
permitted. New features are not allowed. Changes of the required libraries 
are not allowed. String changes for the translators are not allowed. There 
may be exceptions in grave cases, but this has to be discussed in the mailing 
lists. The reason behind this is to make sure that maintenance releases of 
KDE will not break. String changes are prohibited, to make sure that 
translated programs remain translated. The translation teams are to be kept 
free from the burden to do the cleanup that is caused by string changes.
* In the preparation for a new release, there is a time window with 
restrictions, to make sure that a new release will be done. An example can be 
found in 
http://developer.kde.org/development-versions/kde-3.4-release-plan.html

The time window in this case was about 8 weeks long.
The first phase is a feature freeze. Developers had to announce beforehand, 
which features they are still planning to put into the relase. In the time 
from Dec 18th 2004 to Feb 2nd 2005, only checkins for announced features were 
allowed. The idea behind this was to make sure that everybody knows what 
still needs to be done for the release.

Between Feb 2nd 2005 and  Feb 22nd 2005 there was a complete feature freeze 
and message freeze. In this time only bug fixes were allowed. This is to make 
sure that everything works fine with the main release. If everybody was still 
changing lots of things, lots of new errors would occur. But with the freeze, 
there is a chance for developers to hunt those problems down. The message 
freeze means that translators have 3 weeks of time to cleanup remaining 
problems with the translation

After Feb 26 2005, HEAD was open again for development, as any further 
development was made in the branch. 

So that would put some restrictions on bibletime. But on the other hand this 
would also mean that in the preparation for the release, lots of other people 
would build KDE from source and would find out, whethere bibletime compiles 
fine. If you want to be part of KDE, you just have to make sure, that 
everything works fine when the release snapshot is done. So all these rules 
make sense.

> Yes, the community would be the final determiner of this. And judging from
> the kde-look wars when people post Christian artwork, the community may not
> accept us.
We should at least try. After all, Bible time itself is just a program to 
display bible translations. It does contain the bible text. It only allows 
the user to download the text. I think that the community should be tolerant 
enough to tolerate a program that displays a book that 1 third of the worlds 
population consider to be an important pillar of their faith.) And as I said 
before, I would even tolerate Muslims to provide a similar tool for the 
Quran, as this would help me as a Christian to point out its errors and to 
prove that these errors are not just a result of mistranslations as such a 
tool would enable me to find my way through the Arabic text. I think we 
should at least try.

Kind regards,

Heiko Evermann



More information about the bt-devel mailing list