Revisiting the question of a kdebase branch
coolo at kde.org
Thu Apr 13 11:32:10 BST 2006
Am Samstag, 1. April 2006 14:29 schrieb Hamish Rodda:
> 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.
More information about the kde-core-devel