| 2006-12-23 01:13:29 |
Matthew Paul Thomas |
description |
Feature request:
I searched the bug list and there seems to be a couple of reports that hint the need for this.
Requesting a fix is just not simple. It's too confusing. Here is an example:
1. file bug report on software 1.5 (example) for dapper.
2. bug is fixed for edgy as software 2.5
3. bug is important for you, so you need dapper's software fixed too.
Actual result:
4. you get lost in terminology similar to what happens in bug #63418 comment 96[1]
Expected result:
4. You see an option at the left side: "Request fix"
5. Click "Request fix" and choose your version of the product (Dapper, for this example)
6. Developers choose one of three options:
6a. Put newer software in previous product release (which means: put software 2.5 to dapper-updates)
6b. Put patch to older software (which means: put patched software 1.5 to dapper-updates)
6c. Reject (do not provide a fix for dapper's software 1.5)
Doing so will make things easier for everyone:
1. The user won't be tricked into clicking the wrong button
2. The developer will have total control on how the requested fix will (or will not) be delivered to consumer.
The menu would then look like this (simplified a bit more):
* Mark as Duplicate
* Visibility/Security
* Link to CVE
* Also Affects Upstream
* Also Affects Distribution
* Request fix (a syringe as the logo for this?)
* Subscribe
* Subscribe Someone Else
* Comment/Attach File
* Report a Bug in <software>
* Activity Log
[1] https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/63418/comments/96 |
Requesting a fix is just not simple. It's too confusing. Here is an example:
1. file bug report on software 1.5 (example) for dapper.
2. bug is fixed for edgy as software 2.5
3. bug is important for you, so you need dapper's software fixed too.
Actual result:
4. you get lost in terminology similar to what happens in bug #63418 comment 96[1]
Expected result:
4. You see an option at the left side: "Request fix"
5. Click "Request fix" and choose your version of the product (Dapper, for this example)
6. Developers choose one of three options:
6a. Put newer software in previous product release (which means: put software 2.5 to dapper-updates)
6b. Put patch to older software (which means: put patched software 1.5 to dapper-updates)
6c. Reject (do not provide a fix for dapper's software 1.5)
Doing so will make things easier for everyone:
1. The user won't be tricked into clicking the wrong button
2. The developer will have total control on how the requested fix will (or will not) be delivered to consumer.
The menu would then look like this (simplified a bit more):
* Mark as Duplicate
* Visibility/Security
* Link to CVE
* Also Affects Upstream
* Also Affects Distribution
* Request fix (a syringe as the logo for this?)
* Subscribe
* Subscribe Someone Else
* Comment/Attach File
* Report a Bug in <software>
* Activity Log
[1] https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/63418/comments/96 |
|
