about.rst 5.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147
  1. .. _about:
  2. What is Distro Tracker?
  3. =======================
  4. Distro Tracker lets you follow the evolution of a Debian-based
  5. distribution both with email updates and with a comprehensive web
  6. interface. This information may be interesting to package maintainers,
  7. contributors, advanced users, QA members, etc...
  8. Most of the information tracked is about packages but it can be
  9. displayed used in multiple contexts (per package, per maintenance team,
  10. per maintainer, etc.).
  11. Distro Tracker aims to be as extensible and as customizable as possible in
  12. order to allow Debian derivatives to deploy their own instance of Distro
  13. Tracker if they so choose.
  14. .. _email_about:
  15. Email Interface
  16. ---------------
  17. The email interface forwards email messages regarding a package, to users
  18. who are subscribed to that package.
  19. Distro Tracker receives email messages for each package on a special address in the
  20. form of ``<package-name>@<distro-tracker-domain>``. If the local part of the email is a
  21. valid package name, the message is a valid package message. Messages to the
  22. package's address can be sent by either automated tools or users themselves.
  23. Each package email is first tagged with one of the existing keywords and then
  24. forwarded only to the subscribers interested in that keyword. Users sending
  25. package messages to the tracker can tag their own messages with a keyword by using a
  26. local part of the address in the form of ``<package-name>_<keyword>``.
  27. A user can choose which mails they are interested in, by selecting to either
  28. receive messages tagged with one of their "default" keywords or they can choose
  29. a different set of keywords for each of their package subscriptions.
  30. Each vendor can provide their own set of available keywords and a set of rules to
  31. tag incoming messages with one of the keywords. If there is no such tagging
  32. mechanism and no keyword in the local part of the email address, the message is
  33. tagged with the "default" keyword.
  34. The keyword of the forwarded message is included in a mail header
  35. ``X-Distro-Tracker-Keyword``.
  36. There are three types of packages which are considered valid packages for the
  37. email interface:
  38. - source package
  39. - pseudo package - a list of pseudo packages should be provided by a vendor specific
  40. function :func:`distro_tracker.vendor.skeleton.rules.get_pseudo_package_list`
  41. - subscription-only package - neither a pseudo package nor a source package, but
  42. still allows the same email functionality as the other package types
  43. .. _email_control_about:
  44. Email Control Interface
  45. +++++++++++++++++++++++
  46. Users can control their subscriptions (packages subscribed to, keywords to
  47. accept) by sending control commands enclosed in an email message to a robot. The
  48. designated email address for its control interface is ``control@<distro-tracker-domain>``,
  49. by default. This is customizable by vendors.
  50. Control emails contain a list of commands, each in a separate line. Available
  51. commands can be obtained by sending a control message with the ``help``
  52. command (an email message with ``help`` on a single line).
  53. If a message which reaches the control bot contains too many lines which are
  54. invalid commands, processing is halted and only the commands found up until
  55. that point are processed. If there were no valid commands found in the email,
  56. no response is sent, otherwise an email message is constructed and sent in
  57. response to indicate the status of each processed command.
  58. Certain commands may require confirmation by the user, e.g. subscribing to
  59. receive package messages. If a control message contains any such command,
  60. apart from a response email, a separate "confirmation" email is also sent.
  61. Only one confirmation email is sent regardless of how many commands from the
  62. original control message require confirmation. It includes a confirmation
  63. code, instructions on how to confirm the commands and any extra information
  64. about each command which is to be confirmed.
  65. .. _web_about:
  66. Web Interface
  67. -------------
  68. Each source and pseudo package has its own Web dashboard displaying information
  69. aggregated from various sources. This page is accessible at the URL
  70. ``/<package-name>``.
  71. If a binary package name is entered, the user is redirected to the
  72. corresponding source package's page.
  73. A convenient search form is provided on the front page as well as on each
  74. package's page which allows users to jump to another package page. It
  75. supports auto completed suggestions for both source and pseudo packages.
  76. The information currently provided for each package is divided into the
  77. following panels:
  78. - General package information panel
  79. (:class:`GeneralInformationPanel <distro_tracker.core.panels.GeneralInformationPanel>`)
  80. - Versions panel
  81. (:class:`VersionsInformationPanel <distro_tracker.core.panels.VersionsInformationPanel>`)
  82. - Binaries panel
  83. (:class:`BinariesInformationPanel <distro_tracker.core.panels.BinariesInformationPanel>`)
  84. - News panel
  85. (:class:`NewsPanel <distro_tracker.core.panels.NewsPanel>`)
  86. - Bugs panel
  87. (:class:`BugsPanel <distro_tracker.core.panels.BugsPanel>`)
  88. - Action needed panel
  89. (:class:`ActionNeededPanel <distro_tracker.core.panels.ActionNeededPanel>`)
  90. Vendors can easily customize and add new panels to the page. For more
  91. information refer to the
  92. :ref:`design overview documentation <panels_web_design>` regarding panels and
  93. the individual documentation for each of the core panel classes for ways to
  94. extend them.
  95. .. _rss_about:
  96. RSS news feed [coming soon]
  97. +++++++++++++
  98. .. _rest_about:
  99. REST interface [coming soon]
  100. ++++++++++++++
  101. .. _rdf_about:
  102. RDF metadata [coming soon]
  103. ++++++++++++
  104. Command-line Interface
  105. ----------------------
  106. You may use some commands to start some tasks for instance. See the list of available commands with ::
  107. $ ./manage.py --help