Skip to content

NeedsAndFunctionalities

Adrien Gallou edited this page Aug 25, 2014 · 1 revision

NeedsAndFunctionalities

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. See also the roadmap.)

  • 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 updates_testing or backports_testing media
        • 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).

Existing discussions of interest or existing tools/processes

  • 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
    • example of package submitted people can vote, add comments, report bugs, see changes, even see all versions and activity
  • http://screenshots.debian.net