Pushing AppStream upstream metadata to KDE repositories...?

[Alvaro Soliverez]

Hi,
For KMyMoney, just go ahead and commit the file. We'll see the
notification and adjust if needed.

We use GPLv2+ for all our files.

Regards,
Alvaro
KMyMoney Development Team


On Sat, May 10, 2014 at 2:02 PM, Matthias Klumpp <matthias at tenstral.net> wrote:
> Hi there!
> I asked this a week ago, but just got individual replies from two
> people who didn't want changes made to their Git master branches
> currently (not an issue, we handled that via pull-requests and
> reviewboard).
> So I wrote this follow-up, which might be a bit more visible ;-)
>
> Now that we got translations for AppStream upstream metadata working
> (see [1] for an example), the next step is to write metadata for KDE projects.
> I already started with that, partially auto-generating AppStream data
> from our project metadata service (the generated files still need some
> work afterwards, but it's better than nothing)
> I initially thought to send every new metadata through Reviewboard, in
> order to make it visible for the maintainers, who might want to change
> the project's description.
> However, for 160+ files just for KDE applications, without counting
> the frameworks now (which need more love for their metadata, I will
> send every data concerning a framework over Reviewboard, if I created
> it), this simply does not scale
> at all.
>
> Therefore, I would like to ask for feedback on the following proposal:
>  * We announce the availability of the new metadata somewhere, so that
> the individual maintainers know that the data is coming, and that they
> may want to take a look at it when it landed in their Git master
> branch.
>  * I simply go ahead and commit the files to the respective repos.
> Since it's just data, it shouldn't break anything.
>  * Others adjust the initially commited files as they wish. There is a
> quick reference at [2], for those who want to add more data or change
> something.
>  * I'll help with any questions regarding that, of course ;-) - if
> someone doesn't want this, the project can simply opt-out before, or
> revert the commit (but I don't see any reason for doing that, unless
> if someone doesn't want the application to be found ^^).
>
> Would something like that be okay?
> And: What is the license of texts about applications published on
> KDE.org? Can I simply use a permissive license like CC0 (needed in
> order to mix the texts in the distribution later) for them, or is
> there an explicit license specified somewhere? (I wasn't able to find
> information about that)
>
> Cheers,
>    Matthias
>
> [1]: https://projects.kde.org/projects/kde/kdeutils/ark/repository/revisions/master/entry/app/ark.appdata.xml
> [2]: http://techbase.kde.org/MetaInfo
>
> P.S: As a more general question: What makes a KDE project? Do we have
> some guidelines for all projects which they have to follow in order to
> be under the KDE umbrella, or are we more like a Github for Qt
> projects nowadays?
> In case there are guidelines, we might want to add "has AppStream
> metadata" to them in future (when more projects have that data).
>
> --
> Debian Developer | Freedesktop-Developer
> I welcome VSRE emails. See http://vsre.info/