<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 17/03/2013 16:08, melchiaros wrote:<br>
</div>
<blockquote cite="mid:5145DC5D.3040708@aol.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Am 17.03.2013 10:42, schrieb Fabio
Marconi:<br>
</div>
<blockquote
cite="mid:BLU0-SMTP111C6D9EB727FB30D61F96CA5EF0@phx.gbl"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 17/03/2013 01:12, AG Restringere
wrote:<br>
</div>
<blockquote
cite="mid:CALh9bZ1bjsLVXyZyyE8USfv2ZkOVnxBXb-ButQ8bN_PBtM=3ag@mail.gmail.com"
type="cite">Fabio,
<div><br>
</div>
<div>Given these two items:</div>
<div>- Verify the bug is still not fixed</div>
<div>How do you quickly verify if the problem has been fixed?</div>
</blockquote>
<br>
<blockquote
cite="mid:CALh9bZ1bjsLVXyZyyE8USfv2ZkOVnxBXb-ButQ8bN_PBtM=3ag@mail.gmail.com"
type="cite">
<div>What is the process to be used?</div>
</blockquote>
<blockquote
cite="mid:CALh9bZ1bjsLVXyZyyE8USfv2ZkOVnxBXb-ButQ8bN_PBtM=3ag@mail.gmail.com"
type="cite">
<div><br>
</div>
<div> -Request any needed info</div>
<div>What is the specific log(s) and information needed?</div>
<div><br>
</div>
<div>Best,</div>
<div>AG<br>
</div>
<br>
</blockquote>
<font face="Ubuntu">Hallo<br>
<br>
This is one of the cases where it is not possible to reproduce
quickly the issue.<br>
The first thing is to search for duplicates, or scrolling down
the <a moz-do-not-send="true"
href="https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader">ubuntu-release-upgrader
list</a> or googling for: site:bugs.launchpad.net
keywordsrelative and in the case mark as duplicate, obviously
if the bug is fixed in the yellow strip will appear the green
written `Fix released'<br>
This particular package is used to upgrade from one release to
another, so you can understand that the `launchpad' is highly
customized (extra packages, proprietary drivers, personal
settings, unsupported packages, ecc. ecc.).<br>
The only way that we have to reproduce the bug is to recreate
the scenario of the reporter, unless it is not closely
hardware related ( video, audio, devices, ecc.), in a virtual
machine and run the upgrade.<br>
If the bug does not occour to you and it is reported from just
one person, then the probabilty to reproduce it again are near
to 0.<br>
In this case simply tell to the reporter that you are not able
to reproduce the issue, ask for more detailed steps to
reproduce, subscribe youself to the report and set the status
of the bug to incomplete.<br>
Apport automatically attach log files, analyzing them we can
have hints of what happens during the upgrade.<br>
If needed, the relative logfiles can be found on
/var/log/dist-upgrade.<br>
This is an example of error in apt.log:<br>
<br>
MarkUpgrade() called on a non-upgrable pkg: 'brasero'<br>
ERROR:root:Upgrading 'brasero' failed<br>
Log time: 2013-03-15 18:58:20.835223<br>
<br>
This is a managed error:<br>
<br>
Investigating (0) linux-image-extra-3.5.0-18-generic [ amd64 ]
< 3.5.0-18.29 > ( kernel )<br>
Broken linux-image-extra-3.5.0-18-generic:amd64 Depends on
linux-image-3.5.0-18-generic [ amd64 ] < 3.5.0-18.29 > (
kernel )<br>
Considering linux-image-3.5.0-18-generic:amd64 10001 as a
solution to linux-image-extra-3.5.0-18-generic:amd64 -1<br>
Removing linux-image-extra-3.5.0-18-generic:amd64 rather
than change linux-image-3.5.0-18-generic:amd64<br>
Done<br>
<br>
regards<br>
Fabio<br>
<br>
<br>
<br>
<br>
<br>
</font> <br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
Hi Fabio,<br>
<br>
thanks for orgasnisation.<br>
<br>
There is one point I want to discuss:<br>
<br>
You say:<br>
"<br>
<font face="Ubuntu">In this case simply tell to the reporter that
you are not able to reproduce the issue, ask for more detailed
steps to reproduce, subscribe youself to the report and set the
status of the bug to incomplete.<br>
</font></blockquote>
<blockquote cite="mid:5145DC5D.3040708@aol.com" type="cite"><font
face="Ubuntu"> "<br>
This is a bit problematic. Other projects like ubiquity(the
graphical installation system) or the kernel itself has stepped
beside the procedure to reproduce the problem that occure.<br>
<br>
They have good reasons for. Reproducing is often not possible.
And a set to incomplete may blame the user, because s/he want to
give further information, but is simply not able to because the
informations are not available to the user him/herself.<br>
</font></blockquote>
<font face="Ubuntu"> In the case that the log files aren't useful or
not existing we need to investigate in some way, so we have to
interact with the reporter to help research some trace. The
incomplete status makes the bug autoexpire when no reply is done.</font><br>
<blockquote cite="mid:5145DC5D.3040708@aol.com" type="cite"><font
face="Ubuntu"> <br>
As far as I have observed ubiquity has changed the policy of
bughandling to set the priority of the report automatically to
high when the log gives enough information. <br>
The kernel bugs are set automatically to confiremd when they are
reported.<br>
</font></blockquote>
<font face="Ubuntu">Yes, actually we have automated tools doing this
works</font> starting a first triage step.<br>
<blockquote cite="mid:5145DC5D.3040708@aol.com" type="cite"><font
face="Ubuntu"> <br>
I think it makes sense to do some similiar here.<br>
<br>
We should set the status to confirmed if the logs provide enough
information. Independed if the user gives additional
informations to the problem.<br>
</font></blockquote>
<font face="Ubuntu">This things are depending on the degree of
experience of the triager, and I'm not in accord to set the status
to confirmed till the bug is not reproduced on two machine (unless
very particular cases).</font><br>
<br>
Regards<br>
Fabio<br>
</body>
</html>