getting rid of active branches in KDE modules

[Marco Martin]

On Monday 05 September 2011, Aaron J. Seigo wrote:
> hi :)
> 
> after the rather succesful merging of the contour and plasma-mobile
> repositories (after first clearing up the structure of the latter), making
> things a lot easier to work with during development, our next task is
> probably to try and get rid of the branches in kdelibs and kde-runtime
> that we have.
> 
> they are simply another barrier to development and continues to catch
> people.

yep, makes more difficult making people test it

> i merged the changes in the kdelibs activedevelopment/4.7 branch that were
> made to libplasma into the 4.7 branch already. from what i understand, the
> remaining changes are essentially changes to libkactivities.

yes, all in plasma can go to 4.7, rest is libkactivities, there is iirc a 
single change in libnepomuk (that was there + master before it was decided to 
be frozen and not do a 4.8) if the separate nepomuk repository will be used, 
that shouldn't be an issue (and just to be sure i'm still not using that api 
addition i made there)

> 
> in line with the modularization of kdelibs, and following suit with what
> nepomuk has done already as well, i'd like to propose that we break out
> libkactivities into its own git repository. that would kill off that
> particular requirement for a separate branch in kdelibs.
> 
> are there any other developments in that branch that we need? changes to
> libkdeclarative, for instance? if so, can we merge those into the KDE/4.7
> branch?

no changes in libkdeclarative at all ;)

> then we could drop that branch entirely.
> 
> similarly with the branch in runtime .. is there any reason to keep the
> branch alive, or can we simply move to the (really rather slow changing,
> so safe) master branch and merge whatever changes were made in the branch
> into master and/or KDE/4.7 in kde-runtime?

i would be ok for using master, needs green flag from packagers as well.

-- 
Marco Martin