metadata.yaml for Plasma projects?

[Martin Graesslin]

On Thursday, April 7, 2016 1:21:55 PM CEST Aleix Pol wrote:
> On Thu, Apr 7, 2016 at 11:41 AM, Martin Graesslin <mgraesslin at kde.org> 
wrote:
> > Hi Plasmates,
> > 
> > an idea for better documentation is to introduce some metadata similar
> > like
> > what frameworks have. This could be useful for potential devs who want to
> > contribute, but also for distributions as in that way:
> > * we can specify whether it's experimental, released, obsoleted, etc.
> > * what other Plasma projects it depends on
> > * who is maintaining it and where to reach us
> > 
> > Below I have an example how this could look like (in the case of KWin).
> > 
> > What do you think?
> > 
> > Cheers
> > Martin
> > 
> > # The maintainer of the project
> > maintainer: graesslin
> 
> I'd suggest offering an appstream appdata file instead of this.

We have projects for which appstream doesn't make sense. Example is KWin, 
kdecoration, kscreenlocker, kwayland, etc. etc. In fact I think we have more 
projects in Plasma which do not need an appdata file than projects which 
actually benefit from it.

> 
> > # A short description of the project
> > description: X11 Window Manager and Wayland Compositor
> 
> Same
> 
> > # tier 1: depends only on Qt and KDE frameworks
> > # tier 2: depends only on Qt, KDE frameworks and tier 1 Plasma projects
> > # tier 3: depends on Qt, KDE frameworks, tier 1, 2 and 3 Plasma projects
> > tier: 3
> 
> Why?

Because distros gave us the feedback that they have a hard time figuring out 
the dependency chain in Plasma. By introducing this information they know 
better how the build sequence will look like.

> 
> > # Whether the project is obsoleted, if true means it's not included in
> > future # releases any more
> > obsoleted: false
> > # Whether this is an experimental project
> > experimental: false
> > # Whether it's included in releases
> > release: true
> > # The git clone url
> > git: git://anongit.kde.org/kwin
> 
> Isn't that what .git/config will be saying?
> Or "git remote show origin".

Only if you cloned it. But there are also released tars

> 
> > # some code review information on phabricator
> > 
> > phabricator:
> >     # url to the diffusion
> >     diffusion: https://phabricator.kde.org/diffusion/KWIN/
> >     # the review group
> >     reviewer: plasma
> >     # the project it belongs to
> >     project: plasma
> 
> That should be part of .arcconfig.

yes, but the random developer looking at our code has no idea that there are 
hidden files and without knowing anything about arc and phabricator, the random 
dev doesn't know that that's the review tool.

Maybe the naming should be better to highlight that more, e.g:
codereview:
     coderepo: https://phabricator.kde.org/diffusion/KWIN/
    phabricator: #linktothephabtoolijustcannotrememberthe name

> 
> > irc:
> >     network: chat.freenode.net
> >     channel: "#kwin"
> > 
> > mailinglist: kwin at kde.org
> > 
> > bugs:
> >     url: https://bugs.kde.org
> >     product: kwin
> > 
> > dependencies:
> >     - KWayland
> >     - KDecoration
> >     - KScreenLocker
> 
> That's in kde-build-metadata.

No it's not. kde-build-metadata encodes it for the current master and current 
stable branch. It does not encode it for Plasma 5.5.0 release. By putting it 
into git we have it.

Btw. I took that part from frameworks metadata description on our wiki.

> 
> Having duplicated human-read-only information is always bad and will
> only lead us to outdated information.

Yes there is the danger of outdated information. On the other hand it seems to 
work for frameworks.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20160407/2793f3b1/attachment.sig>