Revisiting the question of a kdebase branch

[Stephan Kulow]

Am Samstag, 1. April 2006 14:29 schrieb Hamish Rodda:
> Hi,
>
> The idea of a kdebase_snapshot was turned down earlier due to the desire
> not to create more work with a second major module branch (iirc).
>
> However, although this is in the interests of app developers, it does not
> favour kdelibs trunk developers.
>
> Many changes being made to kdelibs these days really need the developer to
> compile a few sample apps to make sure what they've done is sane.  Once a
> major change has been committed to trunk, other developers either have to
> do local ports of the apps they want to test against, or wait for the next
> snapshot to be able to test again.
>
> Rather than have a kdebase snapshot, what I'm suggesting is to have a
> kdebase-bleedingedge branch which people may commit their ports against.
> When a new kdelibs snapshot is made, kdebase trunk can (optionally) be
> updated with some changes in the bleedingedge branch.  A few days after the
> snapshot, the bleedingedge branch should be overwritten with kdebase trunk,
> and so the cycle continues.
>
> This way, there's no pressure to keep the bleedingedge branch up to date,
> it may just make things more pleasant and share around some of the work for
> kdelibs developers.  In fact, it will hardly consume any resources if not
> needed for a particular period of time.

I think it would still cause a problem as it creates a second target and the 
kdelibs trunk/snapshot split already causes enough confusion on our lists ;(

I see the need though, but I suggest to not have it in general, but open it as 
the need arises.

Greetings, Stephan