KPeople part of KDE Frameworks

[Michael Pyne]

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.

Regards,
 - Michael Pyne