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 <[email protected]> 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/
