policy change related to kdelibs snapshots

[Matthias Kretz]

On Sunday 09 July 2006 21:50, Stephan Kulow wrote:
> So I would like to propose that we use bleedingedge for all modules
> currently in KDE/ and changes to trunk/kdelibs/ should always come with a
> porting of bleedingedge to it.

100% support from me! That's even what I would like to do, but I'm unable to 
because the other changes in trunk/kdelibs break compilation - so whenever I 
adjust kdelibs I have to wait with porting the other modules until the next 
snapshot is made. That I was able to provide the changes for kdebase for my 
KCModule changes was only possible because I kept kdelibs at about the same 
revision as the snapshot. Before committing the kdelibs change I, of course, 
had to update and so after committing to kdelibs was not able to continue 
further development in other modules.

So the rule should be that one revision of trunk/kdelibs and bleedingedge/* is 
compilable? Perhaps not every revision if you don't want to (or can't) do the 
commits in libs and bleedingedge in one go. But we should try to keep the 
times between libs changes and bleedingedge adjustments as small as possible.

And I also support to keep the snapshot/trunk trunk/bleedingedge separation so 
that app developers can work on trunk (without having to recompile everything 
every hour) and kdelibs development + application adjustment can happen at 
the same time.

-- 
C'ya
        Matthias
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060709/43672339/attachment.sig>