Task:Package QA web interface
(Initial page for package QA web interface.) |
(wikify section heagings and list, add links) |
||
| Line 1: | Line 1: | ||
{{task|proposal}} | {{task|proposal}} | ||
| - | = Need = | + | == Need == |
| - | * Developers need to promote their package from extras-devel to extras-testing and extras | + | * Developers need to promote their package from [[extras-devel]] to [[extras-testing]] and [[extras]] |
* Packages need to be tested before they are available for the general public | * Packages need to be tested before they are available for the general public | ||
* Community members should be able to help test applications | * Community members should be able to help test applications | ||
| Line 8: | Line 8: | ||
* Testers should see a list of packages waiting to be tested | * Testers should see a list of packages waiting to be tested | ||
| - | = Workflow = | + | == Workflow == |
| - | == Regular == | + | === Regular === |
A developer uploads a source tarball to the autobuilder. After successful building, this package ends up in extras-devel. | A developer uploads a source tarball to the autobuilder. After successful building, this package ends up in extras-devel. | ||
| Line 24: | Line 24: | ||
Possible outcome: | Possible outcome: | ||
| - | * If a package receives negative feedback, the debmaster will look at the package's problems. If the problem is serious, the package will be removed from the test queue and the author will be notified. | + | * If a package receives negative feedback, the [[debmaster]] will look at the package's problems. If the problem is serious, the package will be removed from the test queue and the author will be notified. |
| - | + | ||
* If the package receives X positive feedback, the package goes to the promotion queue for Extras. | * If the package receives X positive feedback, the package goes to the promotion queue for Extras. | ||
| - | |||
* If the package receives no feedback within X days, the debmaster will look at the package and see what needs to be done. | * If the package receives no feedback within X days, the debmaster will look at the package and see what needs to be done. | ||
When a package is in the promotion queue for Extras, the original uploader (or team) can promote the package to Extras. This makes it easy for the project to time their release. | When a package is in the promotion queue for Extras, the original uploader (or team) can promote the package to Extras. This makes it easy for the project to time their release. | ||
| - | == Exceptions == | + | === Exceptions === |
* Security fixes can be specially handled by debmaster. | * Security fixes can be specially handled by debmaster. | ||
* Fixes for serious bugs can be specially handled by debmaster. | * Fixes for serious bugs can be specially handled by debmaster. | ||
| - | == Implementation questions == | + | === Implementation questions === |
* How would we handle dependencies, when promoting and testing an application. | * How would we handle dependencies, when promoting and testing an application. | ||
* Will we remove a package from extras-testing when it has received X amount of negative feedback or only remove it from the testing queue page. | * Will we remove a package from extras-testing when it has received X amount of negative feedback or only remove it from the testing queue page. | ||
| - | = Inspirational mockup = | + | == Inspirational mockup == |
[https://fedoraproject.org/wiki/MyFedora/Mockups#Package_Details Fedora Packages page] | [https://fedoraproject.org/wiki/MyFedora/Mockups#Package_Details Fedora Packages page] | ||
| - | = Implementation steps = | + | == Implementation steps == |
# Package page | # Package page | ||
Latest revision as of 12:01, 10 March 2011
 |
This task is in the list of maemo.org development proposals, please help planning and getting it ready for a sprint. Put a note on the talk page if you're interested in helping work on this task. Please see the talk page for discussion. |
 |
Contents |
[edit] Need
- Developers need to promote their package from extras-devel to extras-testing and extras
- Packages need to be tested before they are available for the general public
- Community members should be able to help test applications
- Testers should be able to report issues with packages
- Testers should see a list of packages waiting to be tested
[edit] Workflow
[edit] Regular
A developer uploads a source tarball to the autobuilder. After successful building, this package ends up in extras-devel.
extras-devel is considered the development repository, not for end users.
Every package in extras-devel gets an entry in the package web interface. On this page authors can be added to the package and information can be filled in. Default information is gathered from the actual debian package in the repository.
When a developer thinks his application is ready for wider testing and eventually end users, he promotes the package to extras-testing. (Automated QA tests will be performed, but this is outside the scope of this document)
Once the application ends up in extras-testing, the application shows up in the list of packages waiting to be tested. An RSS feed will be available too.
Every community tester can now test the application on their device and report back. The tester can give thumbs up or thumbs down for the package. There is a possibility to file a bug against the package directly OR comments can be left on the package information page, describing the problem the tester encountered.
Possible outcome:
- If a package receives negative feedback, the debmaster will look at the package's problems. If the problem is serious, the package will be removed from the test queue and the author will be notified.
- If the package receives X positive feedback, the package goes to the promotion queue for Extras.
- If the package receives no feedback within X days, the debmaster will look at the package and see what needs to be done.
When a package is in the promotion queue for Extras, the original uploader (or team) can promote the package to Extras. This makes it easy for the project to time their release.
[edit] Exceptions
- Security fixes can be specially handled by debmaster.
- Fixes for serious bugs can be specially handled by debmaster.
[edit] Implementation questions
- How would we handle dependencies, when promoting and testing an application.
- Will we remove a package from extras-testing when it has received X amount of negative feedback or only remove it from the testing queue page.
[edit] Inspirational mockup
[edit] Implementation steps
- Package page
- Promotion page
- Package feedback
- Test queue
- This page was last modified on 10 March 2011, at 12:01.
- This page has been accessed 6,968 times.