Revisiting the question of a kdebase branch

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

What do you think?

Cheers,
Hamish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060401/a35398cc/attachment.sig>