New Prosal [was Re: policy change related to kdelibs snapshots]
coolo at kde.org
Tue Jul 11 10:12:53 BST 2006
Am Dienstag, 11. Juli 2006 10:15 schrieb David Faure:
> > Conflicts within ported code might still happen, but I think it won't be
> > too frequent. Well, all in all, I support Dirk's version.
> ... which is blatantly ignoring the request from most app developers to
> not have to update kdelibs for a period of time before they start working
> on the evening.
Interestingly enough you (Andras) said on kde-commits you stay out of app
development because kdelibs is changing too quickly and drastically. Now
I propose that we make trunk always compiling in making _sure_ we only merge
in compiling changes. And you rather want a trunk that is changing all day
for porting efforts instead of once in a while?
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.
- this did not work out at all. Dirk is right if he says it's hard to do
changes if the code is not compiling and so defect over defect sums up in
the code. This is frustrating for both application developers as it's to
libs developers. And if it wasn't for Laurent, KDE4 development would
already have stopped long ago (Again: thanks Laurent).
- 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.
- For both branches (trunk and bleedingedge) the rule would be that they
should compile at any time and that larger changes should be done in an
extra branch (from where they can go right into trunk the day the
bleedingedge branch is merged - just as we did with dbus)
- Dirk's proposal (from what I understand) is to drop the time based schedule
and develop changes right in trunk. Every developer would have to make sure
his changes are ported out in trunk asap.
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
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).
And I don't see how this would work out in trunk - but I'm willing to try it.
There are several arguments against having an extra branch and I'm very well
aware that many of the problems we see at the moment are derived out of the
So how about we try it with this:
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).
That way application developers don't need to recompile every evening, because
the apps would work with the kdelibs of the evening before, but still kdelibs
developers wouldn't need to apply bugfixes to two branches and we wouldn't
loose SVN history - we could even have grouped commits for the API change and
More information about the kde-core-devel