Framework metadata

[Ben Cooksley]

On Thu, Dec 19, 2013 at 10:53 PM, John Layt <john at layt.net> wrote:
> On 19 December 2013 08:47, Cornelius Schumacher <schumacher at kde.org> wrote:
>> On Wednesday 18 December 2013 Aurélien Gâteau wrote:
>>>
>>> The information in the DOAP file can also be used to generate manifest
>>> files for Inqlude (http://inqlude.org/)
>>
>> For this to work we need at least the following data in the DOAP file:
>>
>> * machine-readable name as identifier (all lower-case, no spaces or other
>> special characters)
>> * human-readable display name
>> * one line short description
>> * longer description (preferably in markdown, so it can be properly formatted
>> independent of the technology used for displaying it)
>> * link to home page
>> * link to source code repository
>> * link to download page of release tarballs (optional)
>> * list of licenses
>> * list of authors (at least one person with a name and an email address)
>> * list of supported platforms
>
> I think I mentioned in the AppData thread the need for a KDE metadata
> file to help us manage our repos, and that all other metadata files
> could be generated from.  This would apply to apps and workspace as
> well as frameworks.  At the time I sketched out some metadata I
> thought would be useful for every KDE repo to have in a .desktop file,
> although more from an internal organisational and end-user viewpoint:
>
> group=[frameworks|workspaces|applications]
> categories=[games|education|multimedia|graphics|...]
> maturity=[experimental|incubator|stable|deprecated|unmaintained]
> release-cycle=[official|independent|unreleased]
> stable-release=<version number>
> stable-release-branch=<git branch>
> stable-release-date=
> unstable-release=
> unstable-release-branch=
> unstable-release-date=
> dev-branch=

Please don't duplicate this information - it is already stored in
kde-build-metadata, in the form of branch group mappings.
Storing it in a single place is much more usable by the various
utilities which need to interact with this information, namely the CI
system and kdesrc-build.

It also duplicates some of the information stored on projects.kde.org,
although that isn't as significant as we plan to replace that at some
point.

> maintainers=<git id>
> name=
> short-description=
> description=
> website=
> forum=
> user-mailing-list=
> dev-mailing-list=
> irc=
> bugzilla=<url>
> bugzilla-product=
> bugzilla-component=
> reviewboard=<url>
> reviewboard-group=
>
> Looking at DOAP, there's a lot of overlap and it looks very flexible
> and if it's being widely adopted then I see it as an option.  The
> XML/RDF is a bit complex/verbose though, any other options available
> out there?
>
> John.

Thanks,
Ben

> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel