metadata.yaml for Plasma projects?

[Scarlett Clark]

+1 to this, and actually I would reuse it for my CI revamp I am working on,
I was working on something similiar, but if the devs keep up their own file
would be even better!
So in short, this would not duplicate kde-build-metadata because that is
going away.
Cheers,
Scarlett

On Thu, Apr 7, 2016 at 4:55 AM, Martin Graesslin <mgraesslin at kde.org> wrote:

> 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
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20160407/baf55257/attachment.html>