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

[Stephan Kulow]

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
required recompilations.

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
snapshot. 

So how about we try it with this:

NEW PROPOSAL:

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
it's porting.

Greetings, Stephan