Announcing the Next Ubuntu Bug Day!

Fabio Marconi marconifabio at hotmail.it
Sun Mar 17 16:39:50 UTC 2013


On 17/03/2013 16:08, melchiaros wrote:
> Am 17.03.2013 10:42, schrieb Fabio Marconi:
>> On 17/03/2013 01:12, AG Restringere wrote:
>>> Fabio,
>>>
>>> Given these two items:
>>> - Verify the bug is still not fixed
>>> How do you quickly verify if the problem has been fixed?
>>
>>> What is the process to be used?
>>>
>>>  -Request any needed info
>>> What is the specific log(s) and information needed?
>>>
>>> Best,
>>> AG
>>>
>> Hallo
>>
>> This is one of the cases where it is not possible to reproduce
>> quickly the issue.
>> The first thing is to search for duplicates, or scrolling down
>> the ubuntu-release-upgrader list
>> <https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader>
>> 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'
>> 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.).
>> 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.
>> 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.
>> 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.
>> Apport automatically attach log files, analyzing them we can have
>> hints of what happens during the upgrade.
>> If needed, the relative logfiles can be found on /var/log/dist-upgrade.
>> This is an example of error in apt.log:
>>
>> MarkUpgrade() called on a non-upgrable pkg: 'brasero'
>> ERROR:root:Upgrading 'brasero' failed
>> Log time: 2013-03-15 18:58:20.835223
>>
>> This is a managed error:
>>
>> Investigating (0) linux-image-extra-3.5.0-18-generic [ amd64 ] <
>> 3.5.0-18.29 > ( kernel )
>> 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 )
>>   Considering linux-image-3.5.0-18-generic:amd64 10001 as a solution
>> to linux-image-extra-3.5.0-18-generic:amd64 -1
>>   Removing linux-image-extra-3.5.0-18-generic:amd64 rather than
>> change linux-image-3.5.0-18-generic:amd64
>> Done
>>
>> regards
>> Fabio
>>
>>
>>
>>
>>
>>
>>
>
> Hi Fabio,
>
> thanks for orgasnisation.
>
> There is one point I want to discuss:
>
> You say:
> "
> 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.
> "
> 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.
>
> 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.
 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.
>
> 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.
> The kernel bugs are set automatically to confiremd when they are reported.
Yes, actually we have automated tools doing this works starting a first
triage step.
>
> I think it makes sense to do some similiar here.
>
> We should set the status to confirmed if the logs provide enough
> information. Independed if the user gives additional informations to
> the problem.
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).

Regards
Fabio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20130317/c35c36f5/attachment.html>


More information about the Ubuntu-bugsquad mailing list