[Ubuntu-bugcontrol] Application for the bugcontrol team

[njin]

Please remember that i can only assign packages, set status (incomplete,
confirmed, invalid) and in the case send upstream.
> > -Is there a particular package or group of packages that you are
> > interested in helping out with? ****Ubiquity, Debian-installer.
> > https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/684083
the only things that i can do is assign package, and as i'm the only reporter i cannot confirm.
> This bug was reported by you and it was triaged by Colin instead.

> > reproduced looking at top ghostscript at 100% of cpu
> > https://bugs.launchpad.net/ubuntu/+source/at-spi/+bug/642888
> > 
> 
> You did identify the package, but the bug here was triaged by Charlie
> (comment#1).
> > Remembering the debugging of gpm i've decided to switch off plymouth at
> > boot, hight set by chris as makes ubuntu unusable for nvidia cards
I cannot triage bugs
> > https://bugs.launchpad.net/launchpad/+bug/692291
> I think you might have quoted the Wrong bug # here?
> This is not an Ubuntu package bug, this is a bug in launchpad itself.
> > But why on this pc don't work and on the other works, ah it's not
> > maximized....i'm the only reporter, importance set by another
Yes, here i get wrong not assigning the package, but at now i cannot
remeber why....
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/390959
> You could have just asked the reporter to run the following command:
> $ apport-collect 390959
> That would have collected all the info that was required , rather than
> the reporter having to attach one file at a time. It would have been a
> lot more easier for the reporter.
> This looks like one of your earlier bugs, but We need to remember the
> tools available to us.
> 
> > just following how to triage
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/480903
> 
> In this bug you did mention apport :)
> But, when requesting information you changed the status from:
>  incomplete -> confirmed , rather you should have left the status as
> incomplete until the apport info was collected.
> 
> Luckily the reported did add info using apport.
> But what if the bug reporter had not? The bug would have been marked
> confirmed without any info.
Yes, too sure of the number of afflicted person
> > missed driver in the kernel. reporter sayd that installing drivers from
> > producer site make it working.
> > https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/674663
> 
> The tagging for this bug is weird and introduces custom tags.
> The correct tag to be used here is `needs-upstream-testing`  and once
> done it just needs to be removed. no need for any new tag.
> Are you sure about the tag 'regression-update' here? There is no
> indication that an update from the maverick-updates caused the bug.

> It seems more like a `regression-release` since the bug was also later
> re-titled. 
> What would have helped was, if the reporter was asked if the problem did
> not exist when he installed Ubuntu 10.10 fresh. And started happening
> only after a particular update. It would narrow-down the cause of the
> bug here.
Ok for the tags, i'm learning, but this is a regression-update, because reporter said 'after first update', and
Stenten has modified the title, and looking the procversionsignature the
installed kernel is 2.6.35-22.35, but the release ship the 2.6.35-22.33

> for more info on tags:
> <https://wiki.ubuntu.com/Bugs/Tags#Kernel%20Specific>
> <https://wiki.ubuntu.com/Bugs/Tags#Regression%20specific>
> <https://wiki.ubuntu.com/Kernel/Tagging>
Thanks!
> 
> 
> > as john lennon sing "with a little help from my friends"
> > https://bugs.launchpad.net/ubuntu/+source/cups/+bug/668800
> 
> This one seems fine. Would have preferred info from the original
> reporter though, but a triager adding the info is also good.
> 
> 
> IMO, The list here would only be 4 bugs that you had triaged for others.
> However, I'v noticed that you have been doing a lot of triaging, but the
> bugs you selected are not a great list. If i had not noticed the work
> you've been doing , based on the bugs listed here I would have -1'd your
> application.
> 
> But, I'm pretty sure you would have a better list of bugs that *you*
> have triaged for others. 
> So +0 for now.
> 
> > i don't remember
> > And many others
> > 
> 
> Have a look at:
> <https://bugs.launchpad.net/~fabiomarconi/+commentedbugs>
> <https://bugs.launchpad.net/~fabiomarconi/+subscribedbugs>
> 
> Try to choose bugs where you have made less mistakes, preferable
> none. :)
i'll look at it this evening
> 
> Have a look at the BugControl criteria:
> <https://wiki.ubuntu.com/UbuntuBugControl#Evaluation%20Criteria%20and%
> 20Process>
> And a few example applications:
> <https://wiki.ubuntu.com/UbuntuBugControl#Example%20Application>
Thanks again!
> 
> Everyone makes mistakes when starting with bug triage, but when
> submitting an application for Bug Control it is better that you list the
> bugs where you have done your *best* work.
Everytime i do my best, there's no one bug different from the other,
also expalining how to set the system is a usability bug.
I don't like to play with the works of other persons.
> If you are not able to find any bugs without mistakes, I'd suggest you
> focus on the packages you are interested in(Ubiquity, Debian-installer)
> and get back with a good bug list.
See you soon
> Looking forward for a better list of bugs.. :)
I think that is more fastest go on
> Also do mention the bug importance that you think is appropriate,
> BugControl are the folks who set these, so it's kinda important that you
> mention along with the bug list too . (Yes, the wiki is ambiguous, looks
> like the wiki needs to be updated and more clear about this. Every
> 'triaged' bug,which is what we request for bugcontrol application, would
> have an importance set, so adding the clause of "does not have an
> importance" is a moot point. Have a look at the application examples.)
> 
> 
Thanks vish to look into this.
Fabio