Projects/AboutData

Requirements analysis

Stakeholders

• Coders
• Translators
• Packagers
• Website authors (http://kde.org/applications/)
• IDE developers
• Users
• Bugzilla masters (bugs.kde.org)

Domain

The description of and other data about a software module. This includes, but is not restricted to:

• Version:
  • identifier ("2.3.2")
  • Alias (2.3 Beta1)
  • codename ("Bummer")
  • release date

• Human-centered data:
  • Authors/Contributors/Copyright holders
  • License
  • Provider
  • Categories/Keywords
  • TitleName, Logo, Icon
  • Short and longer description
  • Homepage
  • Location of Additional Ressources (forum, irc channel, wiki)

• System-integration data:
  • identifier
  • catalog name (translated ui strings)
  • ipc identifier (D-Bus name)
  • location of manual

Problem

Replicated data needs manual synchronisation

Information about a program or plugin is found/used in many places:

• "About" dialog
• desktop file
• application launcher (e.g. KickOff, Lancelot, KRunner)
• Plugin selector
• manual
• homepage
• software package/stores
• bugzilla

On a change of some property all of these places have to be updated/synchronized manually. This at least is needed for the release of a new version of a program, but also once in a while on the change of the homepage, logo or the subtitle.

No official location of the original data

Packagers reported they have to dig up the data they need for the package descriptions, like from somewhere in the code (KAboutData) or files like AUTHORS/THANKS/README/TODO/NEWS/Changelog/..., as there is no official place. Same is true for the project coordinator or others who want to know who is the current official maintainer of a program/plugin. Or the website maintainers who want to update the data on a new release.

Changes in the original data are not propagated

There is no process to spread a change to all places where the data is used. So e.g. the homepage given in a package description can become outdated, same for the icon/logo, because the package still can be built with these outdated data, and most packagers have better to do than actively pull information about changed metadata (as there exist no official way to report such changes downstream).

Wrong or no data

Packagers also often might happen to be no experts in the area of the program, so if there is no original data to copy, they end up guessing most of it, e.g. the description. Or they have to simply leave it out. Developers are often not too eager to maintain even the KAboutData content. Less they are in updating the version info in bugs.kde.org for their product, so only a very few products there have proper versions listed, if at all. Developers of application launchers (Lancelot) have reported interest in longer description of the programs/plugins, like they are used on the website or in package description.

Inconsistent data

Due to the original data not easily found/available it might get recreated. So the program's website might have a different description than the package of the distribution, and the application launcher might have yet another one. So a user of a software might be irritated if the version numbers or the names don't match.

More work done than needed

If the website has a different text for the description of a program than used in the code (KAboutData), it needs to be translated another time. These translations might not even be done, due to lack of infrastructure and menpower.

Automated checks on the metadata impossible

If the metadata is available only implicitely in the code (KAboutData), automated tests like a check for an increased version number for a new release or for if there is an existing maintainer are hard to do.

Little support in IDEs

IDEs like KDevelop or QtCreator might want to integrate the internal project data with the official metadata of the software developed. Besides the initial code creation from a template the project's metadata used by the IDE and in the actual code has to be synchronized by the users. This may be because the IDE developers would have a hard time to track where the metadata is implicitely used in the user's code.

Goal

Obligatory goals (MUST)

• User sees correct, consistent and complete metadata (including translations) in all places

• Webmasters have data about the applications which can be automatically used by the website engine.
• Packagers have a defined place to find the description of a program/plugin.
• Module coordinators and other interested people can find the current maintainer
• Developers of Application launchers have access to a longer description text, including translations
• Developers have to edit just one place.

• All translatable data is available in translations, without large changes in the existing translations system
• Translation of data needs to be done only one time.

• All metadata about a program/plugin is stored together.
• The metadata system is prepared for changes and further evolvement.

Additional goals (MAY)

• Release coordinators can check if the version info is valid for a new release.
• IDE developers can add wizards to edit the metadata and sync with the project data.
• bugs.kde.org automatically gets the new version string on a release.

Non-goals (NEVER)

?

Functional requirements

• Change of the metadata (or translation) is synched automatically:
  • to data copy of website
  • to KAboutData code next build/install of the program/plugin
• Baseformat can automatically be transformed into other formats (KAboutData code, database for application website, package description).
• Baseformat is versionable and extendable for evolving.
• Baseformat has a defined structure with defined types.
• Original data can be easily edited with a text editor
• Data to be translated can be extracted from the data, be feed to the translation system, and be
• Only the data needed is replicated to the metadata copies
• translated data is separately available (useful?)

Ideas, Links

One idea might be to use DOAP. Its goals seem to fit the stated goals above and our use of KAboutData. KAboutData could load the DOAP file from disk on demand, when the user opens the about dialog of the application. --Cloose 12:09, 11 March 2010 (UTC)