policy change related to kdelibs snapshots

[Stephan Kulow]

Am Montag, 10. Juli 2006 01:02 schrieb Michaël Larouche:
>
> So if I develop in kdelibs you mean that I need to maintain TWO trees of
> KDE4 ?
Hmm, well if you want to develop kdelibs, then you only need one tree.
But if you want to develop kdelibs and some app you need indeed another
tree (or svn switch more often :) - but that's exactly the case right now too.

Just that you can right now simply change kdelibs and rely on Laurent to fix 
the rest - which is what I want to change.

>
> I find that overkill and I'm afraid that having many copies of KDE4 would
> cause a management and merge nightmare.
>
> If we need a more dynamic way to develop KDE4, then we should drop
> kdelibs4_snapshot. Maybe that will bring more peoples(i.e applications
> developers) trying to stabilize kdelibs.
I don't want a more dynamic way to develop KDE4, I want a more responsible way 
to develop KDE4.

I have no real problem with dumping kdelibs4_snapshot, but it would most 
likely mean more recompiling for apps developers - even though they could be
more sure it compiles when they start. So both models have pro and contra and 
I guess we should have more input from other TWG members here. 

I see three different options:
1. Leave it as it is
2. Dump kdelibs4_snapshot and make people commiting to kdelibs trunk
   responsible the rest of KDE is ported (in finding aliances) and/or to
   create a porting branch if it's a bigger change.
3. Create a parallel universe to trunk, where the above rules  apply, which is
    then merged into kdelibs4_snapshot/trunk every couple of weeks (we might
    want to make the merging more dynamic then). 

I'd prefer 3.

Greetings, Stephan