<div dir="ltr"><div><div><div>+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!<br></div>So in short, this would not duplicate kde-build-metadata because that is going away.<br></div>Cheers,<br></div>Scarlett<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 7, 2016 at 4:55 AM, Martin Graesslin <span dir="ltr"><<a href="mailto:mgraesslin@kde.org" target="_blank">mgraesslin@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thursday, April 7, 2016 1:21:55 PM CEST Aleix Pol wrote:<br>
> On Thu, Apr 7, 2016 at 11:41 AM, Martin Graesslin <<a href="mailto:mgraesslin@kde.org">mgraesslin@kde.org</a>><br>
wrote:<br>
> > Hi Plasmates,<br>
> ><br>
> > an idea for better documentation is to introduce some metadata similar<br>
> > like<br>
> > what frameworks have. This could be useful for potential devs who want to<br>
> > contribute, but also for distributions as in that way:<br>
> > * we can specify whether it's experimental, released, obsoleted, etc.<br>
> > * what other Plasma projects it depends on<br>
> > * who is maintaining it and where to reach us<br>
> ><br>
> > Below I have an example how this could look like (in the case of KWin).<br>
> ><br>
> > What do you think?<br>
> ><br>
> > Cheers<br>
> > Martin<br>
> ><br>
> > # The maintainer of the project<br>
> > maintainer: graesslin<br>
><br>
> I'd suggest offering an appstream appdata file instead of this.<br>
<br>
</span>We have projects for which appstream doesn't make sense. Example is KWin,<br>
kdecoration, kscreenlocker, kwayland, etc. etc. In fact I think we have more<br>
projects in Plasma which do not need an appdata file than projects which<br>
actually benefit from it.<br>
<span class=""><br>
><br>
> > # A short description of the project<br>
> > description: X11 Window Manager and Wayland Compositor<br>
><br>
> Same<br>
><br>
> > # tier 1: depends only on Qt and KDE frameworks<br>
> > # tier 2: depends only on Qt, KDE frameworks and tier 1 Plasma projects<br>
> > # tier 3: depends on Qt, KDE frameworks, tier 1, 2 and 3 Plasma projects<br>
> > tier: 3<br>
><br>
> Why?<br>
<br>
</span>Because distros gave us the feedback that they have a hard time figuring out<br>
the dependency chain in Plasma. By introducing this information they know<br>
better how the build sequence will look like.<br>
<span class=""><br>
><br>
> > # Whether the project is obsoleted, if true means it's not included in<br>
> > future # releases any more<br>
> > obsoleted: false<br>
> > # Whether this is an experimental project<br>
> > experimental: false<br>
> > # Whether it's included in releases<br>
> > release: true<br>
> > # The git clone url<br>
> > git: git://<a href="http://anongit.kde.org/kwin" rel="noreferrer" target="_blank">anongit.kde.org/kwin</a><br>
><br>
> Isn't that what .git/config will be saying?<br>
> Or "git remote show origin".<br>
<br>
</span>Only if you cloned it. But there are also released tars<br>
<span class=""><br>
><br>
> > # some code review information on phabricator<br>
> ><br>
> > phabricator:<br>
> >     # url to the diffusion<br>
> >     diffusion: <a href="https://phabricator.kde.org/diffusion/KWIN/" rel="noreferrer" target="_blank">https://phabricator.kde.org/diffusion/KWIN/</a><br>
> >     # the review group<br>
> >     reviewer: plasma<br>
> >     # the project it belongs to<br>
> >     project: plasma<br>
><br>
> That should be part of .arcconfig.<br>
<br>
</span>yes, but the random developer looking at our code has no idea that there are<br>
hidden files and without knowing anything about arc and phabricator, the random<br>
dev doesn't know that that's the review tool.<br>
<br>
Maybe the naming should be better to highlight that more, e.g:<br>
codereview:<br>
     coderepo: <a href="https://phabricator.kde.org/diffusion/KWIN/" rel="noreferrer" target="_blank">https://phabricator.kde.org/diffusion/KWIN/</a><br>
    phabricator: #linktothephabtoolijustcannotrememberthe name<br>
<span class=""><br>
><br>
> > irc:<br>
> >     network: <a href="http://chat.freenode.net" rel="noreferrer" target="_blank">chat.freenode.net</a><br>
> >     channel: "#kwin"<br>
> ><br>
> > mailinglist: <a href="mailto:kwin@kde.org">kwin@kde.org</a><br>
> ><br>
> > bugs:<br>
> >     url: <a href="https://bugs.kde.org" rel="noreferrer" target="_blank">https://bugs.kde.org</a><br>
> >     product: kwin<br>
> ><br>
> > dependencies:<br>
> >     - KWayland<br>
> >     - KDecoration<br>
> >     - KScreenLocker<br>
><br>
> That's in kde-build-metadata.<br>
<br>
</span>No it's not. kde-build-metadata encodes it for the current master and current<br>
stable branch. It does not encode it for Plasma 5.5.0 release. By putting it<br>
into git we have it.<br>
<br>
Btw. I took that part from frameworks metadata description on our wiki.<br>
<span class=""><br>
><br>
> Having duplicated human-read-only information is always bad and will<br>
> only lead us to outdated information.<br>
<br>
</span>Yes there is the danger of outdated information. On the other hand it seems to<br>
work for frameworks.<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888">Martin</font></span><br>_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
<br></blockquote></div><br></div>