Proposal to improving KDE Software Repository Organization

Ben Cooksley bcooksley at
Tue Aug 19 21:43:19 UTC 2014

On Wed, Aug 20, 2014 at 9:39 AM, Michael Pyne <mpyne at> wrote:
> On Tue, August 19, 2014 10:18:17 David Faure wrote:
>> On Tuesday 19 August 2014 19:10:14 Ben Cooksley wrote:
>> > The old kf5-qt5 / latest-qt4 names are being mapped to division /
>> > track combinations. They are otherwise not used.
>> Ah!
>> > Just a clarification though: there would only be two divisions for the
>> > above scenario: Plasma5 and KF5.
>> > Plasma5 would then have two tracks: stable and devel. KF5 would have
>> > it's single track.
>> Ah!
>> OK it's a lot clearer to me now.
>> I thought a division was an overall selection of everything
>> (like kf5-qt5 was).
>> Now I see, it's a group of modules, e.g. just KF5, or just Plasma5.
>> This makes a lot more sense, and leads to understandable naming, I like it
>> :)
>> I assume a future kdesrc-buildrc will look like a selection of *one or many*
>> divisions, with a track for each one, then.
> Yes, and branch groups simply become a "pre-tested" set of divisions (I would
> imagine it simply defines the various combinations CI would test in the
> future, though that concept is still up to Ben).
> In the kdesrc-build world you'd still be able to pick divisions (and tracks),
> individual modules, etc.
> There's two feasible ways to go with the "branch-group" option though: It is
> used to pick the right branch or track if not specified, or it is used as CI
> would use it, to pull in an entire set of divisions in one fell swoop. I'm
> open to other ideas, but that's a topic for a separate thread in any event.

The CI system will probably end up relying on divisions directly in
the long run from what I can see at this point.
As an interim measure though, it is likely the branch group concept
will continue to be used though.

I have some other questions for those working on Windows/OS X/Android
CI, but that is a topic for another thread :)

> Regards,
>  - Michael Pyne


More information about the Kde-frameworks-devel mailing list