deeper freeze and kdebindings

[Richard Dale]

On Tuesday 11 November 2003 09:43, Stephan Kulow wrote:
> The actual freeze didn't really work out as expected. The
> rate of reorganizing commits isn't really what it should be
> in this time of release schedule ;(
>
> Starting with tomorrow I'd like to emphasize the release
> freeze even more in applying the following commit rules:
> * all non-oneliner commits have to have an "reviewed by"
>   line where another developer, that can be expected to know
>   the topic, is named that gave his ok.
> * all commits to kdelibs + kdebase have to be posted to
>   kde-core-devel first (the only exception to this are apidocs
>   changes and artwork changes)
>
> Starting with next monday (17.11) the extra rule applies:
> * Every commit to released modules beside kde-i18n have
>   to contain a bug number with severity >= major. I'm trying
>   to watch the activities around bugs.kde.org as close as I can,
>   so make reasonable use of the severities.
Does this apply to the kdebindings module too? In the past I've regenerated 
the java bindings about a week or so before the final release. If I do it too 
early, it only needs one minor change in one kdelibs header to break the 
build, and the kdebindings list gets bug report mails. As far as I know there 
are no translation or artwork dependencies affecting the current JNI based 
java bindings.

I've been working on ruby bindings for a while, but I couldn't put them in the 
KDE 3.2 release schedule, because it was too uncertain when they would be 
finished and whether I'd be able to get them working with the kdelibs classes 
at all. But now I really think the QtRuby bindings are getting to the stage 
where they 'just work', and I'd like to add the extension that allows you to 
do ruby programming under 'kdebindings/kderuby' soon. Then tell people about 
them via an announcement on dot kde news. Is it possible to call the ruby RAD 
stuff a 'technology preview' for the 3.2 release, and only build it if 
specially enabled with a configure option? Then perhaps add them properly on 
the schedule for the 3.2.1 release with a full description, and more code 
samples, documentation and fixes after the preview version.

-- Richard