Revisiting the question of a kdebase branch
rodda at kde.org
Sat Apr 1 13:29:16 BST 2006
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.
What do you think?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
More information about the kde-core-devel