New kdelibs policy starting monday

[Olivier Goffart]

Le samedi 15 juillet 2006 13:01, Stephan Kulow a écrit :
> Hi!
>
> As there doesn't seem to be a real discussion going on anymore,
> I declare the new trunk/KDE policy applying starting this monday.
>
> This means:
>  - next monday we will erase kdelibs4_snapshot and from that time
>     trunk/KDE/kdelibs is the kdelibs to compile against
>  - all of trunk is supposed to compile at any time against that very
>    kdelibs

That mean that the guy which do a small API change need to port and compile 
the whole trunk ?
That's a hard requirement.
(compiling the whole KDE takes me a full week end here)

I would prefer giving the responsibility to the application developper to port 
his application.


>  - Source and binary incompatible changes are only allowed on mondays
>    (on every monday though) and porting efforts should be finished the
>    same evening (that means every developer is allowed to start changing
>    8am her timezone and has to make sure trunk is compiling till 10pm his
>    timezone (being around in #kde4-devel and awaiting people complaining
>    might be enough).
> - Source incompatible changes shall be developed in an extra branch before
>    they hit trunk. As trunk is supposed to compile at any time, you can
> branch off trunk and make your changes till your branch compiles again.

May i suggest a global bleedingedge/kdelibs branch where all minor 
incompatible changes goes ?
so we will not have thousands of branch with cleanup KFoo API or remove KBar 
deprecated method


> Now I hope we can get kdepim and kdewebdev to compile before monday,
> otherwise this policy will be a bit complicated to enforce. And I hope
> everyone makes sure we make this a dynamic process, i.e. update the policy
> if it turns out it's imperfect.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060715/825fcc0f/attachment.sig>