State of Proposal to improving KDE Software Repository Organization?

2016-01-18 Thread Friedrich W. H. Kossebau 
Hi,

(calligra-devel, kexi-devel, kimageshop mailinglists only for heads-up,
 please remove from reply, discussion only on kde-core-devel should be fine)

4 months ago there was the thread "Proposal to improving KDE Software 
Repository Organization" on this mailinglist.
What happened to that plan? Are people preparing its execution?

And would that be a time where some bigger reorganization of the repos is 
possible?

Reason that I ask is that due to the split of Calligra into several repos (see 
background^) the layout in the repo structure does no longer properly reflect 
the project organisation. Right now there are three active repos in the 
calligra/ repo substructure:
"calligra" at "calligra/"
"krita"at "calligra/krita"
"kexi" at "calligra/kexi"

(("calligra" at "calligra/" confuses at least kdesrc-build, sent an email to 
mpyne about if moving it to "calligra/calligra" should fix it.))

Things that are not properly matching organization:
* Krita starting with 3.* no longer is part of Calligra project
  (screws e.g. api.kde.org/bundled-apps-api/calligra-apidocs/ and also
  what people think to which project Krita belongs)
* Calligra & Krita are nowhere different to KDevelop, Digikam & Co,
  so no reason to be in a complete own toplevel structure,
  rather should be in the same sub structure, i.e. "Extragear",
  like extragear/calligra/* and extragear/graphics/krita

More, not only Calligra & Krita related:
* "Extragear" is an awful grouping name for apps with individual
  release plans, a legacy term that no longer fits most of the apps
  in that substructure
* "KDE Applications" is a misleading grouping name for apps with a
  central release plan, as if those with individual release plans
  are not "KDE" applications (as in, not done in the KDE community)
* a single category per app as needed by the current tree structure layout
  of the repos, like "office", "graphics", "utils", is rather awkward,
  many apps do not match exactly one or would match multiple categories

So IMHO some update of the repository organisation would be good, to reflect 
how things are these days.
Renaming of "Extragear" and "KDE Applications" is surely something which needs 
care from promo/marketing/VDG people first to find if that makes sense at all 
and what a good solution would be.
(Being both maintainer of Okteta, which is in "KDE Applications", and meta-co-
maintainer of Calligra, which is not, but still done in the very same KDE 
community, that current naming seems so wrong to me).

But the actual names and grouping aside, for the pure technical renewing 
(which also involves all infrastructure like translation system, 
documentation, phabricator, etc), who is currently planning or working on 
what?
So does it makes sense to wait some more, or should we assume the current 
organization stays for longer, and Calligra & Krita repos should be moved 
inside that organization for now?


^Some background about Calligra repo split, as things are slightly 
complicated:

KRITA)  The "krita" repo was split off, because Krita has finally become a 
full project of its own, separate from Calligra. A logical place for the krita 
repo in the KDE repo structure would perhaps have been somewhere in extragear, 
but at least due to the translators preferring to keep the string catalogs of 
Krita in the "calligra" module as before, for less work, the krita repo was 
for now put as submodule of "calligra/".

KEXI)  Kexi continues to be part of the Calligra project/subcommunity, but the 
Kexi developers preferred a small simple repo "kexi" of their own (for build 
time and size). So the placement at "calligra/kexi" makes perfect sense.

OTHERAPPS)  As the other Calligra apps (Braindump, Karbon, Sheets, Words, 
Stage, etc.) are more tightly coupled and the binary interfaces between libs, 
plugins & apps can still change every other week, for now no further repo 
splitting is planned (to ensure atomic commits on API changes), and they all 
stay in the existing "calligra" repo.


Cheers
Friedrich

Re: State of Proposal to improving KDE Software Repository Organization?

2016-01-18 Thread Ben Cooksley 
On Tue, Jan 19, 2016 at 7:28 AM, Friedrich W. H. Kossebau
 wrote:
> Hi,

Hi,

>
> (calligra-devel, kexi-devel, kimageshop mailinglists only for heads-up,
>  please remove from reply, discussion only on kde-core-devel should be fine)
>
> 4 months ago there was the thread "Proposal to improving KDE Software
> Repository Organization" on this mailinglist.
> What happened to that plan? Are people preparing its execution?

That plan is tied up in other things taking priority / lack of time / etc.
We'll get there eventually. It is also in part related to the Phabricator move.

>
> And would that be a time where some bigger reorganization of the repos is
> possible?
>
> Reason that I ask is that due to the split of Calligra into several repos (see
> background^) the layout in the repo structure does no longer properly reflect
> the project organisation. Right now there are three active repos in the
> calligra/ repo substructure:
> "calligra" at "calligra/"
> "krita"at "calligra/krita"
> "kexi" at "calligra/kexi"
>
> (("calligra" at "calligra/" confuses at least kdesrc-build, sent an email to
> mpyne about if moving it to "calligra/calligra" should fix it.))

Repositories within repositories is a known bad thing to do, the
systems don't handle it properly at all (as it was never an intended
thing you should do). The proper fix is to move the repo to
calligra/calligra (ie. have a "calligra/" top level grouping project).

>
> Things that are not properly matching organization:
> * Krita starting with 3.* no longer is part of Calligra project
>   (screws e.g. api.kde.org/bundled-apps-api/calligra-apidocs/ and also
>   what people think to which project Krita belongs)
> * Calligra & Krita are nowhere different to KDevelop, Digikam & Co,
>   so no reason to be in a complete own toplevel structure,
>   rather should be in the same sub structure, i.e. "Extragear",
>   like extragear/calligra/* and extragear/graphics/krita

In the Phabricator world I had envisioned Extragear as no longer existing.

>
> More, not only Calligra & Krita related:
> * "Extragear" is an awful grouping name for apps with individual
>   release plans, a legacy term that no longer fits most of the apps
>   in that substructure
> * "KDE Applications" is a misleading grouping name for apps with a
>   central release plan, as if those with individual release plans
>   are not "KDE" applications (as in, not done in the KDE community)
> * a single category per app as needed by the current tree structure layout
>   of the repos, like "office", "graphics", "utils", is rather awkward,
>   many apps do not match exactly one or would match multiple categories

Phabricator will allow multiple "categories" to be tagged to a repository...

>
> So IMHO some update of the repository organisation would be good, to reflect
> how things are these days.
> Renaming of "Extragear" and "KDE Applications" is surely something which needs
> care from promo/marketing/VDG people first to find if that makes sense at all
> and what a good solution would be.

Extragear is really an internal structure, not part of marketing so I
think we can go ahead and just kill it...

> (Being both maintainer of Okteta, which is in "KDE Applications", and meta-co-
> maintainer of Calligra, which is not, but still done in the very same KDE
> community, that current naming seems so wrong to me).
>
> But the actual names and grouping aside, for the pure technical renewing
> (which also involves all infrastructure like translation system,
> documentation, phabricator, etc), who is currently planning or working on
> what?

Like most things in this department, Sysadmin...

> So does it makes sense to wait some more, or should we assume the current
> organization stays for longer, and Calligra & Krita repos should be moved
> inside that organization for now?

Not sure how long things are going to take sorry.
Chances are the existing tree will survive in some form (even if it is
only in the XML file various things use) so you may as well do it now.

>
>
> ^Some background about Calligra repo split, as things are slightly
> complicated:
>
> KRITA)  The "krita" repo was split off, because Krita has finally become a
> full project of its own, separate from Calligra. A logical place for the krita
> repo in the KDE repo structure would perhaps have been somewhere in extragear,
> but at least due to the translators preferring to keep the string catalogs of
> Krita in the "calligra" module as before, for less work, the krita repo was
> for now put as submodule of "calligra/".
>
> KEXI)  Kexi continues to be part of the Calligra project/subcommunity, but the
> Kexi developers preferred a small simple repo "kexi" of their own (for build
> time and size). So the placement at "calligra/kexi" makes perfect sense.
>
> OTHERAPPS)  As the other Calligra apps (Braindump, Karbon, Sheets, Words,
> Stage, etc.) are more tightly coupled and the binary interfaces between libs,
> plugins & apps

Re: State of Proposal to improving KDE Software Repository Organization?

2016-01-18 Thread Ben Cooksley 
On Tue, Jan 19, 2016 at 8:27 AM, Boudewijn Rempt  wrote:
> On Mon, 18 Jan 2016, Friedrich W. H. Kossebau wrote:
>
>> Reason that I ask is that due to the split of Calligra into several repos
>> (see background^) the layout in the repo structure does no longer properly
>> reflect the project organisation. Right now there are three active repos in
>> the calligra/ repo substructure:
>> "calligra" at "calligra/"
>> "krita"at "calligra/krita"
>> "kexi" at "calligra/kexi"
>
>
> What I'm wondering is, where is this "structure" actually visible? Not in
>
> https://quickgit.kde.org/

Quickgit shows the raw git repository structure, which deliberately
does not include the tree in it.

>
> or
>
> https://phabricator.kde.org/diffusion/

Eventually we'll have projects for each broader category (Multimedia,
Graphics, etc) and repositories will be tagged for those.
Phabricator will never provide a repository tree though (nor should
it, the existing tree is a hell of a maintenance nightmare).

>
> I see it reflected in the old, to be discarded
>
> https://projects.kde.org/projects
>
> But where else? And what is it actually needed for?

The build metadata depends on it, and it is used by:

- The CI system
- API / LXR / EBN
- Scripty.
- kdesrc-build

>
>>
>> (("calligra" at "calligra/" confuses at least kdesrc-build, sent an email
>> to mpyne about if moving it to "calligra/calligra" should fix it.))
>>
>> Things that are not properly matching organization:
>> * Krita starting with 3.* no longer is part of Calligra project
>>  (screws e.g. api.kde.org/bundled-apps-api/calligra-apidocs/ and also
>>  what people think to which project Krita belongs)
>> * Calligra & Krita are nowhere different to KDevelop, Digikam & Co,
>>  so no reason to be in a complete own toplevel structure,
>>  rather should be in the same sub structure, i.e. "Extragear",
>>  like extragear/calligra/* and extragear/graphics/krita
>>
>> More, not only Calligra & Krita related:
>> * "Extragear" is an awful grouping name for apps with individual
>>  release plans, a legacy term that no longer fits most of the apps
>>  in that substructure
>
>
> It's ghastly -- almost insulting. It's perpetuating the fallacy that
> there are core KDE projects and peripheral projects.

I agree. Which is why i'd like to see the Extragear moniker dropped.
If repositories are part of some broader release unit (like KDE
Applications - even if this does have a better name) then they still
need to visible as belonging to it though I think.

>
>> * "KDE Applications" is a misleading grouping name for apps with a
>>  central release plan, as if those with individual release plans
>>  are not "KDE" applications (as in, not done in the KDE community)
>
>
> Horrible as well.
>
>> * a single category per app as needed by the current tree structure layout
>>  of the repos, like "office", "graphics", "utils", is rather awkward,
>>  many apps do not match exactly one or would match multiple categories
>
>
> Honestly, the need to group repositories is, to me, so weird that I think it
> would be best to adopt the following scheme:

Note that "Frameworks", "KDevelop" and "KDE Telepathy" are all fairly
logical groupings of repositories (and things would be completely
unmanagable in so many ways if we didn't have these).

>
> a/amarok
> a/...
> ...
> c/calligra
> g/gcompris
> k/krita
>
> And so on. It's meaningless as it is; it would be better to make that clear,
> if grouping is really needed.
>
>> So IMHO some update of the repository organisation would be good, to
>> reflect how things are these days.
>> Renaming of "Extragear" and "KDE Applications" is surely something which
>> needs care from promo/marketing/VDG people first to find if that makes sense
>> at all and what a good solution would be.
>
>
> That again begs the question: where is the "organization" which apparently
> has
> purely technical reasons visible to contributors and users?
>
>> (Being both maintainer of Okteta, which is in "KDE Applications", and
>> meta-co-
>> maintainer of Calligra, which is not, but still done in the very same KDE
>> community, that current naming seems so wrong to me).
>>
>> But the actual names and grouping aside, for the pure technical renewing
>> (which also involves all infrastructure like translation system,
>> documentation, phabricator, etc), who is currently planning or working on
>> what?
>> So does it makes sense to wait some more, or should we assume the current
>> organization stays for longer, and Calligra & Krita repos should be moved
>> inside that organization for now?
>>
>>
>> ^Some background about Calligra repo split, as things are slightly
>> complicated:
>>
>> KRITA)  The "krita" repo was split off, because Krita has finally become a
>> full project of its own, separate from Calligra. A logical place for the
>> krita repo in the KDE repo structure would perhaps have been somewhere in
>> extragear, but at least due to the translators preferring to keep

Re: PSA: KAccounts now requires two env vars set

2016-01-18 Thread Weng Xuetian 
I just wonder whether it is some work for startkde or something to be
installed under /etc/xdg/plasma-workspace/env/ . If so maybe add a
file to kaccounts and install it under /etc/xdg/plasma-workspace/env/
then you won't need to bother packagers to figure out how to make it
work.

On Mon, Jan 18, 2016 at 12:06 PM, Martin Klapetek
 wrote:
> Because of a co-installability issue with other DEs [1]
> that use the accounts-sso tech, I had to change the location
> of the provider and service files we ship. This was decided
> after discussing with upstream.
>
> To make KAccounts/libaccounts actually read those from
> the new locations, two new env variables will be needed:
>
> AG_PROVIDERS=/path/to/providers
> AG_SERVICES=/path/to/services
>
> So please make sure you add them to your systems.
> Distro people - please make sure this is set in Plasma
> sessions (and ideally in Plasma sessions only).
>
> Your existing accounts should not be affected by this change.
>
> However you won't be able to add new or change accounts
> if you don't have these two env vars set. It's recommended
> to clean rebuild all things installing providers or services
> (currently known to me are ktp-accounts-kcm, kaccounts-providers
> and purpose iirc).
>
> This change will affect the Applications 16.04 release.
>
> [1] - https://bugs.kde.org/show_bug.cgi?id=347219
>
> Cheers
> --
> Martin Klapetek | KDE Developer

PSA: KAccounts now requires two env vars set

2016-01-18 Thread Martin Klapetek 
Because of a co-installability issue with other DEs [1]
that use the accounts-sso tech, I had to change the location
of the provider and service files we ship. This was decided
after discussing with upstream.

To make KAccounts/libaccounts actually read those from
the new locations, two new env variables will be needed:

AG_PROVIDERS=/path/to/providers
AG_SERVICES=/path/to/services

So please make sure you add them to your systems.
Distro people - please make sure this is set in Plasma
sessions (and ideally in Plasma sessions only).

Your existing accounts should not be affected by this change.

However you won't be able to add new or change accounts
if you don't have these two env vars set. It's recommended
to clean rebuild all things installing providers or services
(currently known to me are ktp-accounts-kcm, kaccounts-providers
and purpose iirc).

This change will affect the Applications 16.04 release.

[1] - https://bugs.kde.org/show_bug.cgi?id=347219

Cheers
-- 
Martin Klapetek | KDE Developer

Re: State of Proposal to improving KDE Software Repository Organization?

2016-01-18 Thread Jaroslaw Staniek 
On 18 January 2016 at 20:27, Boudewijn Rempt  wrote:

> On Mon, 18 Jan 2016, Friedrich W. H. Kossebau wrote:
>
> Reason that I ask is that due to the split of Calligra into several repos
>> (see background^) the layout in the repo structure does no longer properly
>> reflect the project organisation. Right now there are three active repos in
>> the calligra/ repo substructure:
>> "calligra" at "calligra/"
>> "krita"at "calligra/krita"
>> "kexi" at "calligra/kexi"
>>
>
​Thanks ​Friedrich, as always you introduce great amount of structure and
logic to KDE projects :)

It's even a bit more interesting that that; there are sub-sub-projects
playground/libs/kdb
playground/libs/kproperty
playground/libs/kreport​


- all historically and by heart ​being part of Calligra. In the future
Calligra _initiative_ can contain repos from any "category", why not?
Everyone can. See below for simple solutions to have that.


> What I'm wondering is, where is this "structure" actually visible? Not in
> ​​
>
> https://quickgit.kde.org/
>
> or
>
> https://phabricator.kde.org/diffusion/
>
> I see it reflected in the old, to be discarded
>
> https://projects.kde.org/projects
>
> But where else? And what is it actually needed for?
>

​build.kde.org's config (I remember that only because ​

​today I edited it: https://git.reviewboard.kde.org/r/126797 )​
Is this visible on the web page? No idea.
e.g. https://build.kde.org/view/Calligra/ groups some Calligra builds with
direct deps, that's all.

I know chiliproject.org that's used for projects.kde.org would better be
not patched. I hope this can be solved somehow and we can model our KDE
structures by our tools, not the other way round.


>
>> (("calligra" at "calligra/" confuses at least kdesrc-build, sent an email
>> to mpyne about if moving it to "calligra/calligra" should fix it.))
>>
>> Things that are not properly matching organization:
>> * Krita starting with 3.* no longer is part of Calligra project
>>  (screws e.g. api.kde.org/bundled-apps-api/calligra-apidocs/ and also
>>  what people think to which project Krita belongs)
>> * Calligra & Krita are nowhere different to KDevelop, Digikam & Co,
>>  so no reason to be in a complete own toplevel structure,
>>  rather should be in the same sub structure, i.e. "Extragear",
>>  like extragear/calligra/* and extragear/graphics/krita
>>
>> More, not only Calligra & Krita related:
>> * "Extragear" is an awful grouping name for apps with individual
>>  release plans, a legacy term that no longer fits most of the apps
>>  in that substructure
>>
>
> It's ghastly -- almost insulting. It's perpetuating the fallacy that
> there are core KDE projects and peripheral projects.
>

​Trees are dead. ​

I'd suggest a flat structure:
- relations between apps is a graph not a tree anymore (Kexi can be both in
office /productivity category as well as software development like KDevelop)
- it's 2016, people search, not browse

Or if categorization is needed, on top of the flat structure, tags are the
real means for that that people understand

There are app description formats: .lsm, .appdata.xml... I use them for
Kexi. Some others too. .lsm supports keywords.

I think semantic tags would be best (or do we use them already?).
A repo can be in a subproject and also belong to a number of categories.


>
> * "KDE Applications" is a misleading grouping name for apps with a
>>  central release plan, as if those with individual release plans
>>  are not "KDE" applications (as in, not done in the KDE community)
>>
>
> Horrible as well.
>

Yes, it's a surprise even to KDE people. Here, Calligra and KDevelop, to
name just them, are not KDE Apps to normal people.


>
> * a single category per app as needed by the current tree structure layout
>>  of the repos, like "office", "graphics", "utils", is rather awkward,
>>  many apps do not match exactly one or would match multiple categories
>>
>
> Honestly, the need to group repositories is, to me, so weird that I think
> it would be best to adopt the following scheme:
>
> a/amarok
> a/...
> ...
> c/calligra
> g/gcompris
> k/krita
>
> And so on. It's meaningless as it is; it would be better to make that
> clear,
> if grouping is really needed.
>
> So IMHO some update of the repository organisation would be good, to
>> reflect how things are these days.
>> Renaming of "Extragear" and "KDE Applications" is surely something which
>> needs care from promo/marketing/VDG people first to find if that makes
>> sense at all and what a good solution would be.
>>
>
> That again begs the question: where is the "organization" which apparently
> has
> purely technical reasons visible to contributors and users?
>
> (Being both maintainer of Okteta, which is in "KDE Applications", and
>> meta-co-
>> maintainer of Calligra, which is not, but still done in the very same KDE
>> community, that current naming seems so wrong to me).
>>
>> But the actual names and grouping aside, for the pure technical