Announcing the Next Ubuntu Bug Day!

[Brian Murray]

On Sun, Mar 17, 2013 at 04:08:13PM +0100, 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.
> 
> 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.

They are automatically set to High if there is a crash found in a bug
reported by apport.  This is done as an initial sorting method in the
bugs to differentiate them from ones like
http://launchpad.net/bugs/1155571.

> The kernel bugs are set automatically to confiremd when they are reported.

I believe this is only done if they are reported by apport and for
similar reason to ubiquity.

> 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 is changing the definition of Confirmed for this specific package
which is not something I want to do.  The kernel team does this due to
the large volume of bug reports that they receive.

--
Brian Murray
Ubuntu Bug Master
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20130318/9e14ddcc/attachment.pgp>