[KDE-i18n-nl] [Kde-cvs-announce] Message (un)freeze for KDE 3.5 branch

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[KDE-i18n-nl] [Kde-cvs-announce] Message (un)freeze for KDE 3.5 branch

coolo (Bugzilla)
Hi!

I was awaiting the opening of the KDE4 translation branch (as this was done
from stable branch I didn't want a mixture). As this happened, I'd like to
open the KDE 3.5 branch again (it doesn't have a deadline yet, I'll announce
the deadline early).

Let me quote my mail for those new to KDE:

The requirements for a new feature to get in KDE3.5.x are:

- it needs to be already in trunk - we already have lot of code that went only
into KDE3.5.x and not trunk, no need to make this even worse

- it needs to be complete and ready - don't ask "I plan to develop this
feature for 3.5.x, will it get in?"

- it needs to be well-tested - create a branch or a patch and have it tested
by other people, or even make independent public releases (kde-apps.org, in
some distribution packages, whatever)

- it needs to respect other freezes - if no new i18n messages are allowed, no
feature changing those is allowed either

- it needs to be committed no later than a month before the next release is
tagged

- it must be mentioned in the changelog of the release (marked with "New:")

- commit log must include "approved by ..." and don't forget the FEATURE: tag
where applicable

- last and the most important: It must be posted to the mailing list for the
SVN module (kde-core-devel for those without) and must be approved by the
module's maintainer (TWG for those without)

For the GUI strings (also known as messages), you can fix typos and make
 small changes to them. You can also add new error messages to improve error
 feedback to users. (Adding other kinds of messages are not allowed. In case
 of questions or doubts, please ask the [hidden email] mailing list.)

For the documentation, the changes should also be rather small, except when
fixing inaccurate or outdated documentation. You can also port documentation
that has been prepared in the trunk/KDE modules. (If you change any
documentation for the KDE 3.5 branch, please be sure that the change is also
in the corresponding module of trunk/KDE. However you can do a little later,
in case that you would not have much time during the lift period.)

Greetings, Stephan
_______________________________________________
Kde-cvs-announce mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/kde-cvs-announce
_______________________________________________
Kde-i18n-nl mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/kde-i18n-nl