Add a "fix or workaround" field to bug

This would help the bug database become more useful as a knowledge base. But I think including any workaround in the Description field would work just as well. Having a separate field wouldn't help people find workarounds in bug listings: some people would keep including workarounds in comments (just as they currently use comments for things that should ideally be part of the description), and conversely people would often forget (or not bother) to blank the workaround field after further discussion revealed that the proposed workaround didn't work.

Benefit #3 could also be achieved by tweaking the caption for the Description field.

What do you think of using a 'workaround' tag?

What would a workaround tag be used for? I'm trying to imagine someone searching for bugs that contain workarounds, or searching for bugs that don't contain workarounds. Both seem a bit implausible.

On Sun, Sep 03, 2006 at 01:35:22AM -0000, Matthew Paul Thomas wrote:
> What would a workaround tag be used for? I'm trying to imagine someone
> searching for bugs that contain workarounds, or searching for bugs that
> don't contain workarounds. Both seem a bit implausible.

You're right, it's not useful for searching. The idea of using a 'workaround' tag would be to show, in the bug page near the description, that the bug has a workaround.

--
Diogo M. Matsubara

kiko, Bjorn, what do you guys think of a Bug.workaround field?

On Mon, Sep 18, 2006 at 09:42:17PM -0000, Brad Bollenbach wrote:
> kiko, Bjorn, what do you guys think of a Bug.workaround field?

The idea itself isn't too bad, it would probably encourage people to
add workarounds to bugs (since it's easier to know that you could do it
if there's a special field for it, rather than having it be part of the
description). The downside is that it would be yet another thing on the
bug page, so I think it would be better to try to drive the users to
add it to the description instead.

On 19-Sep-06, at 3:15 AM, Björn Tillenius wrote:

> On Mon, Sep 18, 2006 at 09:42:17PM -0000, Brad Bollenbach wrote:
>> kiko, Bjorn, what do you guys think of a Bug.workaround field?
>
> The idea itself isn't too bad, it would probably encourage people to
> add workarounds to bugs (since it's easier to know that you could
> do it
> if there's a special field for it, rather than having it be part of
> the
> description). The downside is that it would be yet another thing on
> the
> bug page, so I think it would be better to try to drive the users to
> add it to the description instead.

I think the pros outweigh the con of adding a new field. And:

   * a workaround can affect bug heat, probably by decreasing it
slightly
   * release managers can worry slightly less about bugs that have
workarounds

The problems mpt mentioned of people continuing to put workarounds in
comments, and people not changing or removing inaccurate workarounds
is the same when using the description; if anything, I think a
separate field will increase the likelihood of it being kept accurate
and up-to-date.

We discussed about this idea again during UDS Oneiric in Budapest.
I didn't know about this bug so I've started writing a spec for it. Here's the link:

https://wiki.ubuntu.com/BugsKnownWorkAround

Nice spec. Want to kick off a discussion about this on launchpad-dev?

I will. Thanks for the suggestion. :)

I don't believe in explaining solutions in the Description field because I did that, writing "Solution: ...", and some surveillant-looking person removed it, without explanation of course, maybe on the ground that it is not a description.
The purpose of a Solution field is not search, but would be the official place where a general user is told *what to do* to solve his problem instead of having to decode a complicated and often contradictory tech discussion and finding nothing or finding "fixed".
That problem is not restricted to workarounds but concerns any fix: the Solution: field would contain install package(s) "name version or later" (instead of fixed) and/or "do this...".

BTW, the depots should keep previous (superseded) versions of the packages. This is because a correction can introduce other mistakes. I experienced that several times, lately because of the "latest kernel", my system was going mad. But fortunately, one can downgrade a kernel and I was counting on that and it made me most happy. Isn't that the goal?

On Sat, Dec 05, 2015 at 10:07:56PM -0000, André Pirard wrote:
> I don't believe in explaining solutions in the Description field because I did that, writing "Solution: ...", and some surveillant-looking person removed it, without explanation of course, maybe on the ground that it is not a description.

Any proposed solution field would be editable in the same way, so no
change there. But I think you drastically overestimate how much time
people competent to write solution fields would have to fill such a
thing in; time spent on such things has to be traded off against time
spent fixing other bugs, and developers are often working pretty close
to capacity already.

> BTW, the depots should keep previous (superseded) versions of the
> packages.

There is no possible way that archive.ubuntu.com (a widely-mirrored
site) could realistically have space to do this; the instant result
would be a significant reduction in the number of sites willing to
mirror Ubuntu. However, it's possible to download old versions from
launchpad.net.

> This is because a correction can introduce other mistakes. I
> experienced that several times, lately because of the "latest kernel",
> my system was going mad. But fortunately, one can downgrade a kernel and
> I was counting on that and it made me most happy. Isn't that the goal?

Not really, because the logical consequence of what you're asking for,
at least if proper ethical behaviour is applied, is that every old
version has to be security-supported. That does not come close to being
feasible. Managing regressions is a real problem, but this isn't a good
solution.

> Any proposed solution field would be editable in the same way, so no
> change there.
Not understood.

> But I think you drastically overestimate how much time
> people competent to write solution fields would have to fill such a
> thing in; time spent on such things has to be traded off against time
> spent fixing other bugs, and developers are often working pretty close
> to capacity already.
Remember that I have done it and I can tell that for somebody who knows which packages to install to fix the bug it takes less than 5 min to fill that "field".
On the other hand, you seem to underestimate the time that hundreds or thousands of people may spend to find that information and just find "fixed". I've done that too and it took me days.
Spending 5 min to spare the human kind more than 1000 hours is well spent time.
On the first foot, the uncontested goal of this ticket, filling in workaround information, usually takes much more time than a simple copy&paste of a package ID.
And that's why I don't understand your first remark, why the field would be called workaround and hence not be filled with fix descriptions.

Because of the insistence that bug #1509453 is a duplicate of this one, I have (almost) merged the titles.

>> BTW, the depots should keep previous (superseded) versions of the
>> packages.
> There is no possible way that archive.ubuntu.com (a widely-mirrored
> site) could realistically have space to do this; the instant result
> would be a significant reduction in the number of sites willing to
> mirror Ubuntu.
I don't believe that (especially when I see Google offer gigabytes to millions of accounts).
In any case, a single server containing the old versions, and to be used (or logically appended to mirrors) only when one wants to downgrade would be sufficient.

Think twice and notice that providing old versions is the way to enable some genius to write a "Restore my system to a previous state (date)" à la Windows.

> However, it's possible to download old versions from
> launchpad.net.
Interesting hidden info. Could you be specific and show how to to download, for example, the previous or 3-numbers-old version of Ubuntu Firefox? Or of any package.

>> This is because a correction can introduce other mistakes. I
>> experienced that several times, lately because of the "latest kernel",
>> my system was going mad. But fortunately, one can downgrade a kernel and
>> I was counting on that and it made me most happy. Isn't that the goal?
> Not really, because the logical consequence of what you're asking for,
> at least if proper ethical behaviour is applied, is that every old
> version has to be security-supported. That does not come close to being
> feasible. Managing regressions is a real problem, but this isn't a good
> solution.
?????
An old version is an old version and is, of course, not supported otherwise than by installing an (existing) newer version !!!!!! Returning to an old version lasts for the time the reason to do so remains and has not been fixed (by a fix of the last fix).

The bottom line of all this is that, without some way to downgrade erroneous fixes like Windows users can do, I have to tell the Ubuntu us...

I'm afraid I do not have the time to argue further about most of this;
sorry. I'll respond to this part:

On Tue, Dec 08, 2015 at 09:53:44PM -0000, André Pirard wrote:
> > However, it's possible to download old versions from
> > launchpad.net.
> Interesting hidden info. Could you be specific and show how to to download, for example, the previous or 3-numbers-old version of Ubuntu Firefox? Or of any package.

Using a web browser, start here and follow links:

  https://launchpad.net/ubuntu/+source/firefox/+publishinghistory

More programmatically, this is all available via the Launchpad API -
binary packages can be fetched from binary_package_publishing_history
objects:

  https://help.launchpad.net/API/launchpadlib

On 2015-12-08 23:11, Colin Watson wrote:
> I'm afraid I do not have the time to argue further about most of this; sorry. I'll respond to this part:
> On Tue, Dec 08, 2015 at 09:53:44PM -0000, André Pirard wrote:
>>> However, it's possible to download old versions from launchpad.net.
>> Interesting hidden info. Could you be specific and show how to to download, for example, the previous or 3-numbers-old version of Ubuntu Firefox? Or of any package.
> Using a web browser, start here and follow links: https://launchpad.net/ubuntu/+source/firefox/+publishinghistory

Thanks!!! Indeed I found my way through the links down to the DEBs that would have saved me days.
(The Web had shown me only to generic versions of the old DEBs)
But that's not for the general users and I still don't know how to do that for all the other packages easily.
If all those binaries were in a depot to use with Synaptic's Properties>versions & Package>Force version...
(like I do on my local depot hack) it would be a thing done for everybody's almost simple life.
And note that it's not a question of adding DEBs to a depot, but of not removing them !!!

Please save Ubuntu users days.