New Prosal [was Re: policy change related to kdelibs snapshots]

[Dirk Mueller]

On Tuesday 11 July 2006 11:12, Stephan Kulow wrote:

> Let me try to summarize some points:
> - we created kdelibs4_snapshot so that there is some time for apps
> developers in between porting efforts and to have some kdelibs changes
> summing up before we have app developers to port their apps to it.

And it was bad because it bundled together nobrainer API updates with big 
class refactorings that weren't even tested.

> - so my proposal is to give libs developers a branch where they can sort
> out new kdelibs changes and these changes are merged into trunk as one.

This is my proposal as well, but I want each major refactoring in a separate 
branch (Kmessagebox broken? yay! KSystemTray changed in a very incompatible 
way all at once? yay!).

Right now we have to wait 2 more weeks until we can fix the mess which would 
have otherwise not been merged at all or could have been fixed within 1-2 
days. Thats undesireable, and hurts KDE libs development. I don't see the 
point in trying to stall kdelibs development if we don't even have a plan on 
what is in there, when it should be Preview-ready, etc. Also, app developers 
are really confused on in which direction KMessageBox or KSystemTray are 
heading now. All in all, this mess is pregenerated by the automated 
bleeding-merges. 

> Actually the only problem I can see with Dirk's proposal is the objection
> of quite some application developers against dropping the 2 week cycle. I
> guess quite some concerns are about the never ending porting efforts and
> the always required recompilations.

Again, I did not say that app developers are bothered with mere portings. 
trunk changes must not break compile, so by definition you can't commit 
something to kdelibs that breaks compilation in some module, without fixing 
the module at the same time. It would also be desireable to remove deprecated 
API in the modules before removing it from kdelibs. 

> My most important requirement at this point is that library developers are
> required to make sure their API changes make sense (in either porting the
> apps for themselves or writing good porting guide material on use cases).

The most important point is that we have a structured way on when to merge 
refactorings (most importantly when ther was a branch where a snapshot of KDE 
compiled against, and when the API change was reviewed). Didn't we talk about 
API reviews and kdelibs teams forever on the meeting and now its all 
forgotten again? Great to see that the new kind of thunder didn't even last 
one week. 

> And I don't see how this would work out in trunk - but I'm willing to try
> it

It won't happen in trunk. Anything non-nobrainer will happen in a branch. if 
you're afraid that the O(1) branch operation in subversion is too expensive, 
then we can create a make-it-cool-branch, as long as there is no time based 
merge of the make-it-cool-branch to trunk.  

> We forget about the snapshotting as it, but don't allow BIC/SIC changes to
> kdelibs trunk outside of mondays - and these commits have to come with a
> prepared port of all modules in trunk/KDE and koffice. Then every developer
> can decide for himself if he wants to prepare that change locally or if he
> would join a group effort in the bleedingedge branch (which then would
> require bleedingedge kdelibs).

Fine with me. 


Dirk