From Fedora Project Wiki
(Created page with "= Fedora Improvements = This page sums suggestions on the improvement of Fedora policy, guidelines, lifecycle, and more. == Suggestions == === Packages passing automaticall...")
 
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 21: Line 21:


* '''Proposed solution #1:''' Don't close bugs automatically after a time period.
* '''Proposed solution #1:''' Don't close bugs automatically after a time period.
=== Serious Rawhide regressions tracking bug ===
* '''Problem:''' There is no way urgent bugs that seriously break rawhide are managed (not talking about crashes and abrt).
* '''Proposed solution #1:''' Create a 'serious rawhide regression tracking bug'. Anyone can nominate bugs to get added to that and we have a pool of people watching it who can fix or nag maintainers to fix such issues as a higher priority. We would need to come up with some critera for acceptance there.
=== Using [rawhide] tag on the devel list ===
* '''Problem:''' There is no established way of informing rawhide users about workarounds etc. on a timely basis
* '''Proposed solution #1:''' Prepend rawhide problems-related discussion subject with [rawhide]
=== Usability tests ===
* '''Problem:''' Fedora does not have usability tests
* '''Proposed solution #1:''' Have an easy way of setting up a VM and testing in it. Testing if a package builds is easily done in mock, but e. g. for GUI it's less than ideal.
----
This page contains suggestions and ideas from these people (alphabetically): Kevin Fenzi, Mikolaj Izdebski, Stanislav Ochotnicky, Paulo César Pereira de Andrade, Tomas Radej

Latest revision as of 15:17, 21 December 2012

Fedora Improvements

This page sums suggestions on the improvement of Fedora policy, guidelines, lifecycle, and more.

Suggestions

Packages passing automatically from rawhide to stable branch

  • Problem: Packages automatically pass from rawhide to the stable branch, which threatens the stability of the build if that package is largely unmaintained.
  • Proposed solution #1: Do not move packages to the stable branch if there is a critical bug filed against it.
  • Proposed solution #2: The maintainer must opt in for the package to go to the stable branch.

Review system is not very user friendly

  • Problem: The review process requires the reviewer to do a lot of steps that could be eliminated - download the package, build it, run fedora-review etc.
  • Proposed solution #1: Build package automatically upon submitting, run automatic fedora-review tests, so that the reviewer only has to do manual tests.

Bugs are closed as WONTFIX automatically after some time

  • Problem: Packages are being closed as WONTFIX after some time, which makes tracking poorly-maintained packages more difficult
  • Proposed solution #1: Don't close bugs automatically after a time period.

Serious Rawhide regressions tracking bug

  • Problem: There is no way urgent bugs that seriously break rawhide are managed (not talking about crashes and abrt).
  • Proposed solution #1: Create a 'serious rawhide regression tracking bug'. Anyone can nominate bugs to get added to that and we have a pool of people watching it who can fix or nag maintainers to fix such issues as a higher priority. We would need to come up with some critera for acceptance there.

Using [rawhide] tag on the devel list

  • Problem: There is no established way of informing rawhide users about workarounds etc. on a timely basis
  • Proposed solution #1: Prepend rawhide problems-related discussion subject with [rawhide]

Usability tests

  • Problem: Fedora does not have usability tests
  • Proposed solution #1: Have an easy way of setting up a VM and testing in it. Testing if a package builds is easily done in mock, but e. g. for GUI it's less than ideal.

This page contains suggestions and ideas from these people (alphabetically): Kevin Fenzi, Mikolaj Izdebski, Stanislav Ochotnicky, Paulo César Pereira de Andrade, Tomas Radej