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

Albert Astals Cid aacid at kde.org
Tue Mar 6 22:38:35 GMT 2007


A Dimarts 06 Març 2007, vàreu escriure:
> 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

What if there is no code in trunk. I'm specifically thinking in merging xpdf 
3.02 code into kpdf from 3.5 branch. There is no kpdf on trunk and okular is 
not having embedded sources of xpdf.

This (yet to be finished) merge fixes lots of bugs and it would really be a 
good idea having it in kde 3.5.7

Albert

> - 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 kde-i18n-doc at kde.org 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
> Kde-cvs-announce at kde.org
> https://mail.kde.org/mailman/listinfo/kde-cvs-announce






More information about the kde-core-devel mailing list