I just received a user not found message from my reply for [email protected] . I suggest that no one bother replying until he provides a valid address.
Micah On 08/18/2010 10:19 PM, Micah Gersten wrote: > Replying inline as one message > > On 08/18/2010 05:40 PM, Micheal Harker wrote: >> oops I clicked send there by accident. The reply is AFTERthe original >> message. >> >> On 18 Aug 2010, at 23:16, Micheal Harker < >> <mailto:[email protected]> >> <mailto:[email protected]>[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> 1. Do you promise to be polite to bug reporters even if they are rude >>> to you or Ubuntu? Have you signed the Ubuntu Code of Conduct? >>> >>> Yes. I have signed the Code of Conduct and yes I will be polite >>> whenever someone my hurt me of my feelings for ubuntu. I believe >>> CONSTRUCTIVE criticism will make Ubuntu even better. > > The goal is to *always* be polite *even if* one is insulted. > >>> --------------------------------- >>> 2. Have you read Bugs/HowToTriage, Bugs/Assignment, Bugs/Status and >>> Bugs/Importance? Do you have any questions about that documentation? >>> >>> Nope, It seems pretty straight forward and I use Ubuntu on a Day so I >>> can check some bugs out then. Also, If I had any questions on the >>> matter as they arise I can ask on IRC before carrying out an action. > > Well, there seems to be an issue with posting responses which we'll get > to down with the bugs. > >>> --------------------------------- >>> 3. What sensitive data should you look for in a private Apport crash >>> report bug before making it public? See Bugs/HowToTriage for more >>> information. >>> >>> I defiantly heard from there that if a CoreDump.gz is attached then >>> make the report private. The file may contain sensitive information >>> but I have to subscribe myself first. > > Well, stacktraces can also contain private data. > >>> --------------------------------- >>> 4. Is there a particular package or group of packages >>> that you are interested in helping out with? >>> >>> Acctually no, I am a sorta what We should call "all rounder" at buy >>> reporting and answering. I try to get all the new Bugs sorted and as >>> being as I have lots of time let's see If I can get the list down to a >>> manageable number using what the wiki page tells us :) >>> --------------------------------- >>> 5. Please list five or more bugs which you have triaged. These bugs >>> should demonstrate your understanding of the triage process and how to >>> properly handle bugs. For *each* of these bugs, please point out what >>> Importance (and reasoning) you would give it after becoming a member >>> of Ubuntu Bug Control. Please use URLs in your list of bugs. >>> >>> Bug #616538 - I chose medium for severity and Medium was decided upon. >>> This is because some people may want to install the package but can't. > > On this bug, you posted a link to the comment text instead of the actual > comment. There seems to be an issue with the confirmed state, but I'll > bring that up in a separate mail to the list. Is this bug in Maverick > as well which has the 2.6.35 kernel? We normally don't support the > mainline kernel in any release. There was talk of a Maverick kernel > being backported for Lucid for certain uses, but I haven't seen that > yet. Why was this bug accepted? > >>> >>> Big #616536 - I thought the severity should have been medium. It was >>> picked Medium I said It was because if a ubuntu use likes that >>> screensaver and has some work ing >>> > > Once again you posted the link to the response instead of actually > responding. Were you able to reproduce this in a Maverick Live CD > environment? > > <snip signature, repeat text /> >> Anyway Let me continue >> >> If the user wanted to have the screensaver but had apt running he would >> soon find out apt broke because of it. Not Good. >> >> Bug #616581 - I decided Medium again but the bug was classified as high. >> I thought it should of been medium because It wouldn't affect the >> majority of users. But now I understand why it is high. > > Yes, High is appropriate since it makes the default install unusable. > >> Bug #619532 - This bug was triaged in Ubuntu (as well as 100 paper >> cuts). I decided on Low because It could annoy people just the tiniest >> bit. But I was set to wishlist which is even better than low for this. I >> also understand why It was wishlist material. > > Wow, this bug is a doozy, there's a list of issues: > 1. We don't know where the user is trying to change the password. That > might affect where the bug should have been assigned. > 2. The bug was upstreamed without a link back to Launchpad bug. > 3. The bug description was copied and pasted upstream without checking > to make sure it made sense. This was noted by one of the Debian > Maintainers (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593513#18) > 4. I was not given a status for this bug. I was just asked that it > should be "Triaged". (Yes I should've asked, but I was busy). > 5. The triager created an atmosphere of hurry in the channel that this > needed to be completed immediately. This led to issues 1-3 not being > properly addressed by the Bug Control members that were helping. (We're > at fault too in this case). > Triage requires a cool head and calm to insure that the proper actions > are taken. This keeps us from wasting the time of Ubuntu developers, > upstream developers, and reporters. > >> Bug #616446 - It was suggested at low and It had gotten the Low status I >> decided on Low because It wasn't really Wishlist nor Important It was >> just a general issue that didn't need to have the same priority as other >> big massive bugs because It Network manager was perfectly fine but It >> just needed that tweak. It was fixed in a later update. > > This bug is Incomplete which means that it has not been triaged to > completion in one way or another. There's really not enough information > to tell what the importance should be at this time. If it's > reproducible, it might be medium since the package might be installable. > > The main difference between Bug Squad and Bug Control is being able to > determine when a bug has enough information for Developers (to set > Triaged) and set the Importance. While you do have some understanding > of the Importance, I do not believe that you understand what constitutes > a bug with enough information yet. Furthermore, while you are very > eager to help which is a good thing, I think you need to slow down and > ask more questions. I would suggest getting a mentor and trying to > specialize in one or several areas where you have a good understanding > of how the packages in question work so that you can easily test > reproducible steps and know what's necessary for triage. > > Given mentoring and some time, I think you can be a great help, but at > the moment I have to give your application a -1. > > Micah > > _______________________________________________ > Mailing list: https://launchpad.net/~ubuntu-bugcontrol > Post to : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-bugcontrol Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol More help : https://help.launchpad.net/ListHelp
