KPeople part of KDE Frameworks

[Ben Cooksley]

On Wed, Mar 4, 2015 at 2:00 PM, Michael Pyne <mpyne at kde.org> wrote:
> On Tue, March 3, 2015 08:29:16 Marko Käning wrote:
>> > With that said, kdesrc-build *will* ignore modules that have a defined
>> > branch of "" (i.e. empty) in logical-module-structure, so if a module
>> > simply should not be built for a given branch-group my recommendation
>> > would be to define the branch-group after all but set it to an empty
>> > value. E.g.
>> >
>> >        "kde/kdenetwork/ktp*": {
>> >
>> >            "stable-qt4": "kde-telepathy-0.9",
>> >            "latest-qt4": "kde-telepathy-0.9",
>> >            "kf5-qt5": "master",
>> >            "stable-kf5-qt5": ""
>> >
>> >        },
>> >
>> > I believe that Scarlett's new CI supports this as well, and the current
>> > Jenkins CI also supports this.
>>
>> Scarlett’s CI also supports to treat *undefined* entries as _set to empty_,
>> just like my OSX/CI does.
>>
>>    So, in the light of your remarks the question is, whether all the
>>    removed empty definitions in my RR [1] should actually be left the
>>    way they are!?!?
>
> Hi Marko,
>
> There's a reason I'd mentioned kdesrc-build's current behavior in my reply to
> that RR. :)
>
> I personally would retain empty entries. But kdesrc-build can and should
> change to adapt to what's best for KDE development. As I mentioned in the RR,
> if we're now at a state where every module that should be recorded in kde-
> build-metadata *is* recorded in kde-build-metadata (so that a user can build
> any KDE git repository using kdesrc-build) then I would certainly be willing
> to change the behavior of kdesrc-build to reflect the CI.
>
> But that would be a significant behavior change, especially for lesser-used
> modules (e.g. in playground/) that don't necessarily receive CI coverage, but
> which users and developers may still want to build via kdesrc-build. It would
> still be possible to build such modules without kde-build-metadata defined for
> them, but users would have to manually add the module using something like
>
> module playground-foo
>   repository kde:kfancyfoomodule
> end module
>
> I think the real solution (so that we don't need empty branch-group hacks)
> would come from finally implementing the proposal Ben and I had made back in
> August 2014 (currently just an email thread in kde-frameworks-devel
> https://mail.kde.org/pipermail/kde-frameworks-devel/2014-August/018391.html).
>
> I ran out of time to do effectively any development for some months after
> that, so as far as I know there's been no progress. But that's the direction
> we *intend* to head... now would be a good time if you want to review the
> proposal to see if it would help or hurt your efforts.

I concur that the real fix at this point is to update the file format
to the new iteration we developed last year and get that rolled out.

>
> Regards,
>  - Michael Pyne

Cheers,
Ben

> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel