**UPDATE : mageia-app-db now has a project's website : http://madb.org **











The project's goal is to address the following listed needs, through a web application (hopefully hosted on mageia servers), which could be the main access point for users searching for information on the available packages, backports requests and new soft requests handling.

In what follows, I will suppose that the release cycle is a stable release every x months, with security/bugfix updates and backports for version updates. However, most of what follows still applies for a rolling release.

===Which needs do we want to address?===
(roughly prioritized : **high priority**, //medium priority//, lower priority but nice to have)
- __for packagers, testers and users__:
- **find information about available packages for each Mageia release (stables + cauldron)**
- **link to project's homepage + changelogs for updates**
- **maintainer name**
- **latest news**
- **latest security/bugfix updates**
- **latest backports**
- **(for testers) latest packages in testing or backports_testing**
- **push information (rss, mail, twitter?) for security/bugfix updates and backports**
- //localized description (when available, english standard summary from the RPM otherwise)//
- //screenshots//
- //list known issues in Mageia for this package (from bugzilla)//
- //package popularity (bases on which stats? Votes? Pages views? Mirror stats?)//
- user/packagers/testers comments
- //links to useful resources about this package (mageia wiki, blogs, ...)//
- //other classical package information//
- stats on package usage, if possible
- **see only information your are interested in:**
- **customization (which releases you want to follow, and if you want which packages groups, which packages you want to follow)**
- __for users__:
- **easily request backports / vote for an existing backport request**
- **easily request new software integration in repositories / vote for an existing software request**
- //easy access to bug tracker for the selected application/package//
- //application view rather than just a package view ?//
- **download package**
- //download source package//
- one-click package installation
- ability to contribute better descriptions for existing packages (as they say many package descriptions are useless)
- __for testers__
- **easy opt-in as tester for specific packages ou package groups**
- __for packagers__
- **collect and see users' needs (backports, new softs)**
- **request for testing (especially for update candidates and package version upgrade (aka backports) candidates)**
- **empower users into testers ("you asked for this backport, please test it and report back. Do you accept to test future backports for this package too?")**// or even into packagers (see which new apps users requested, and try to build the src.rpm for it)//
- __others__
- //have official package pages which can be linked from upstream projects websites or used by other distributions to find easily information about our packages (can be particularly useful for localized short summary and description.//
- cross-distribution comparisons of packages will sometimes require to identify different naming of packages among distributions (particularly for libs)

People can be packagers for some packages (or package groups), testers for others, and simple users for the remaining packages, need to take that into account.

===Some constraints:===
- Simple yet powerful UI
- Make it outstand anything done by other distros (well, make it just work at first) :)
- integration into Mageia website (using the LDAP user database). If possible, nice to have : SSO (single sign on).

===Why a dedicated application and not just using bugzilla?===
- Far simpler to use UI than bugzilla for users.
- Bugs still go to bugzilla.
- user front-end can be translated (if requesting a backport is as simple as choosing the package name and version)
- we define what the database contains, so we can add whatever useful information we need about packages (for users, testers and/or packagers)
- if packagers really really need bugzilla tickets to work, there may be a way to create them automatically from the new app
- packagers can learn to use a new app for backport requests and new package requests. Yes they can :)

===What about Sophie?===
Ideally, mageia-app-db and Sophie's efforts would be joined, in order to see together where mageia-app-db stops and where sophie comes at rescue, how mageia-app-db could benefit from sophie's vast knowledge on the package database, and maybe how to merge some features of the web frontend between sophie.zarb.org and mageia-app-db.

===What's the name of this project?===
At the moment, « mageia-app-db », but I'm sure we can find a better name when it'll be in production, because it's not very appealing :)

===Already available resources for this project===
- project lead
- Samuel Verschelde (Stormi)
- specifications, development
- Adrien Gallou (ttp)
- Samuel Verschelde (Stormi)
- alpha/beta testing, translations
- Rémi Verschelde (Akien)
- Daniel Tartavel
- Marianne Lombard (Jehane)
- interaction with Sophie / common features merge if needed / help using the RPM databases : Olivier Thauvin (Nanar)

===Resources needed for the project development===
- mageia board approval, so that this project can become mainstream (with LDAP integration, mageia.org integration...) : DONE https://mageia.org/pipermail/mageia-discuss/20101103/002873.html and http://meetbot.mageia.org/mageia-meeting/2010/mageia-meeting.2010-11-02-20.05.html
- see roadmap at http://github.com/agallou/mageia-app-db
- other devs : LATER in the development process, when we have a list of tasks which can be delegated
- artwork (we have to make a pretty web application) : depends on Mageia Guidelines. When they're ready we'll welcome contributions
- translators (first version can be english only, but localization is planned from a technical point of view from the start)

===ROADMAP ===
Here is a first draft for the roadmap : http://github.com/agallou/mageia-app-db/wiki/ROADMAP

===Existing discussions of interest or existing tools/processes===
Some discussions can contribute to some parts of this project.
~- https://mageia.org/pipermail/mageia-dev/20101025/001356.html maintainer groups, for some packages we have more than one people willing to work on that package
~~- http://maintainers.mandriva.com/listpkgs.php?owner=1 existing list of unmaintained packages
~~- http://sophie.zarb.org/stat/Mandriva,cooker stats of packages / packagers
~- https://mageia.org/pipermail/mageia-discuss/20101024/002586.html One problem in choosing packages is that for many a description of what the app does is sparse or nonexistent
~~- http://mdk.jack.kiev.ua/stats/doc/trunk/po/ Mandriva Tools Localization Stats for rpm-summary-contrib.po, rpm-summary-main.po...
~- https://mageia.org/pipermail/mageia-discuss/20101024/002601.html Some people could review current packages, some other could write proper description, a third set will review it, and the last part of the group will organize this with packagers and push the description to cauldron.
~~- http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis good practices for descriptions
~- LibreOffice is thinking of using Pootle, which seems to be appropriate from their discussions. See : http://translate.sourceforge.net/wiki/pootle/index and : http://en.wikipedia.org/wiki/Pootle
~- Maemo QA process for applications : http://bergie.iki.fi/blog/application_quality_assurance_in_linux_distributions/
~~- http://wiki.maemo.org/Extras-testing#How_it_works_in_practice
~~- [[http://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/lugdulov/0.3.0-2/ example of package submitted]] people can vote, add comments, report bugs, see changes, even [[http://maemo.org/packages/view/lugdulov/ see all versions and activity]]



----
CategoryMageiaDev