From jff at jff-webhosting.net Thu Jan 2 12:45:43 2014 From: jff at jff-webhosting.net (=?ISO-8859-1?Q?J=F6rg_Frings-F=FCrst?=) Date: Thu, 02 Jan 2014 13:45:43 +0100 Subject: new IRC-Channel Message-ID: <1388666743.14135.18.camel@merkur> Hi, first I wish a Happy New Year to everybody. I'm working on bug review for some times. And I hope that my work is ok. I want to initiate a new IRC channel: #ubuntu-bug-de I don't want that we get a chat for each language. But I think for the main languages ​​(Chinese, Spanish and German) should be possible. And we must have enough native speakers in BugSquard. What's your opinion about it? CU Jörg -- Jörg Frings-Fürst JFF-Software Inh. Jörg Frings-Fürst Friedhofstraße 2 54526 Niederkail Tel.: +49 6575 6219054 Fax: +49 6575 6219055 Umsatzsteuer-ID: DE-227673985 PGP-Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A Key-Server: hkp://keys.gnupg.net ######### S/MINE (X.509) Zertificat von CACert SN 0D:9A:12 SHA1-Fingerprint: 35:DC:C9:EA:4B:38:DA:AB:70:6C:AD:3D:03:B9:4D:A3:EE:2C:EF:43 MD5-Fingerabdruck: 0E:E8:5D:31:84:4D:4B:14:43:E0:C0:38:95:F2:30:DD Verschlüsselte EMails sind gerne gesehen. Ausschlusserklärung: Diese E-Mail nebst Anlagen kann vertrauliche und/oder rechtlich geschützte Informationen enthalten. Der Inhalt dieser E-Mail ist ausschließlich an einen bestimmten Empfänger bzw. Empfängerkreis gerichtet. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte umgehend den Absender der Nachricht. Die Nutzung, das Kopieren sowie die unbefugte Weitergabe dieser E-Mail sind nicht gestattet. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3707 bytes Desc: not available URL: From teward at ubuntu.com Thu Jan 2 20:41:02 2014 From: teward at ubuntu.com (Thomas Ward) Date: Thu, 2 Jan 2014 15:41:02 -0500 Subject: new IRC-Channel In-Reply-To: <1388666743.14135.18.camel@merkur> References: <1388666743.14135.18.camel@merkur> Message-ID: What's wrong with the current IRC channel, #ubuntu-bugs? ------ Thomas LP: ~teward 2014/1/2 Jörg Frings-Fürst : > Hi, > > first I wish a Happy New Year to everybody. > > > I'm working on bug review for some times. > And I hope that my work is ok. > > > I want to initiate a new IRC channel: #ubuntu-bug-de > > I don't want that we get a chat for each language. > > But I think for the main languages (Chinese, Spanish and > German) should be possible. And we must have enough native > speakers in BugSquard. > > > What's your opinion about it? > > CU > Jörg > > > -- > > Jörg Frings-Fürst > JFF-Software > Inh. Jörg Frings-Fürst > Friedhofstraße 2 > 54526 Niederkail > > Tel.: +49 6575 6219054 > Fax: +49 6575 6219055 > > Umsatzsteuer-ID: DE-227673985 > > PGP-Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A > Key-Server: hkp://keys.gnupg.net > ######### > S/MINE (X.509) Zertificat von CACert SN 0D:9A:12 > SHA1-Fingerprint: 35:DC:C9:EA:4B:38:DA:AB:70:6C:AD:3D:03:B9:4D:A3:EE:2C:EF:43 > MD5-Fingerabdruck: 0E:E8:5D:31:84:4D:4B:14:43:E0:C0:38:95:F2:30:DD > > Verschlüsselte EMails sind gerne gesehen. > > > Ausschlusserklärung: > > Diese E-Mail nebst Anlagen kann vertrauliche und/oder rechtlich > geschützte Informationen enthalten. Der Inhalt dieser E-Mail ist > ausschließlich an einen bestimmten Empfänger bzw. Empfängerkreis > gerichtet. Wenn Sie nicht der richtige Adressat sind oder diese > E-Mail irrtümlich erhalten haben, informieren Sie bitte umgehend > den Absender der Nachricht. > Die Nutzung, das Kopieren sowie die unbefugte Weitergabe dieser > E-Mail sind nicht gestattet. > > > > > > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > From jff at jff-webhosting.net Fri Jan 3 10:22:05 2014 From: jff at jff-webhosting.net (=?ISO-8859-1?Q?J=F6rg_Frings-F=FCrst?=) Date: Fri, 03 Jan 2014 11:22:05 +0100 Subject: new IRC-Channel In-Reply-To: References: <1388666743.14135.18.camel@merkur> Message-ID: <1388744525.11511.3.camel@merkur> Hi Thomas, nothing is wrong. I think we can use it to improve our support for bugs for German-speaking people. On Do, 2014-01-02 at 15:41 -0500, Thomas Ward wrote: > What's wrong with the current IRC channel, #ubuntu-bugs? > nothing is wrong. I think we can use it to improve our support for bugs for German-speaking people. > ------ > Thomas > LP: ~teward > Jörg > 2014/1/2 Jörg Frings-Fürst : > > Hi, > > > > first I wish a Happy New Year to everybody. > > > > > > I'm working on bug review for some times. > > And I hope that my work is ok. > > > > > > I want to initiate a new IRC channel: #ubuntu-bug-de > > > > I don't want that we get a chat for each language. > > > > But I think for the main languages (Chinese, Spanish and > > German) should be possible. And we must have enough native > > speakers in BugSquard. > > > > > > What's your opinion about it? > > [...] -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3707 bytes Desc: not available URL: From amjjawad at gmail.com Fri Jan 3 10:28:29 2014 From: amjjawad at gmail.com (Ali Linx (amjjawad)) Date: Fri, 3 Jan 2014 14:28:29 +0400 Subject: new IRC-Channel In-Reply-To: <1388744525.11511.3.camel@merkur> References: <1388666743.14135.18.camel@merkur> <1388744525.11511.3.camel@merkur> Message-ID: On Fri, Jan 3, 2014 at 2:22 PM, Jörg Frings-Fürst wrote: > Hi Thomas, > > nothing is wrong. > > I think we can use it to improve our support for bugs for > German-speaking people. > > Hi, I have always thought that was the purpose of Loco Teams :) -- Remember: "All of us are smarter than any one of us." Best Regards, amjjawad Areas of Involvement My Projects -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergioandresmeneses at gmail.com Sun Jan 5 15:15:08 2014 From: sergioandresmeneses at gmail.com (Sergio Meneses) Date: Sun, 5 Jan 2014 10:15:08 -0500 Subject: new IRC-Channel In-Reply-To: References: <1388666743.14135.18.camel@merkur> <1388744525.11511.3.camel@merkur> Message-ID: but you can use the same channel to talk in another languages!... I mean, you can invite people from Germany and make a session about -reporting or fixing bugs and I think there will be no problem with that. Sergio Meneses Linux User: #478743 Ubuntu User: #24056 On Fri, Jan 3, 2014 at 5:28 AM, Ali Linx (amjjawad) wrote: > > On Fri, Jan 3, 2014 at 2:22 PM, Jörg Frings-Fürst wrote: > >> Hi Thomas, >> >> nothing is wrong. >> >> I think we can use it to improve our support for bugs for >> German-speaking people. >> >> > Hi, > > I have always thought that was the purpose of Loco Teams :) > > > -- > Remember: "All of us are smarter than any one of us." > Best Regards, > amjjawad > Areas of Involvement > My Projects > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hggdh2 at ubuntu.com Wed Jan 8 16:01:25 2014 From: hggdh2 at ubuntu.com (C de-Avillez) Date: Wed, 8 Jan 2014 10:01:25 -0600 Subject: new IRC-Channel In-Reply-To: References: <1388666743.14135.18.camel@merkur> <1388744525.11511.3.camel@merkur> Message-ID: <20140108100125.16051405@icatu> On Sun, 5 Jan 2014 10:15:08 -0500 Sergio Meneses wrote: > but you can use the same channel to talk in another languages!... I > mean, you can invite people from Germany and make a session about > -reporting or fixing bugs and I think there will be no problem with > that. Not quite. The language at #ubuntu-bugs is (as in most of the common channels) English. Although every so often we can have a small dialog in a different language, this does not make it an accepted practice. In summary: the language at #ubuntu-bugs is English. Only English. Now, with that taken care of (or so I hope), back to #ubuntu-bugs-xx. I am sort of against it: #ubuntu-bugs is dedicated to working on bugs, with emphasis in *triaging*. It is NOT the ideal channel for: * is this patch correct? * how do I prepare a debdiff? * I installed Ubuntu, and my whatchamacallit is not working, what gives? * how do I print (or stamp, cement, read, paint, jump, whatever) in *buntu? * etc I can see some questions like the above localised -- they deal with usage, mostly. But I fail to see how a question about *triaging a bug* would make sense only in German (or Portuguese, or Italian, or whatever). Triaging is performed in English, after all. On the other hand, I can see localisation helping a LOT when a group of people join to discuss specific issues -- for example, how to reproduce bug 123457890. The ensuing discussion will most likely get to be complex, and having it done in one's native (or authoritative) language would make it much more easier. I have a feeling this is actually what Jörg intended. And I am all in favour of this approach. AS LONG AS... #ubuntu-bugs keeps on being the primary, authoritative bug triaging channel -- there HAS to be a place where a final answer can be produced. Cheers, ..C.. -- ab alio expectes alteri quod feceris -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From noreply at ubuntu.com Sun Jan 12 01:33:49 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 12 Jan 2014 01:33:49 -0000 Subject: =?utf-8?q?New_attachment_added_to_page_DebuggingPrintingProblems_on_Ubunt?= =?utf-8?q?u_Wiki?= Message-ID: <20140112013349.10373.80311@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page "DebuggingPrintingProblems" for change notification. An attachment has been added to that page by rgrieger. Following detailed information is available: Attachment name: Printer Trouble Report Attachment size: 12911 Attachment link: http://wiki.ubuntu.com/DebuggingPrintingProblems?action=AttachFile&do=get&target=Printer+Trouble+Report Page link: http://wiki.ubuntu.com/DebuggingPrintingProblems From noreply at ubuntu.com Tue Jan 14 19:42:01 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Tue, 14 Jan 2014 19:42:01 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingPrintingProblems=22_by_?= =?utf-8?q?pascal-devuyst?= Message-ID: <20140114194201.7191.6659@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingPrintingProblems" page has been changed by pascal-devuyst: http://wiki.ubuntu.com/DebuggingPrintingProblems?action=diff&rev1=87&rev2=88 Comment: Remove printingbuginfoscript (no longer supported) = Reporting Bugs = Beginning with 9.04, Jaunty Jackalope, to report printing bugs use 'ubuntu-bug cups' which will gather useful information about your system related to printing like the version of Ubuntu you use, configured printers and the versions of important printing packages installed and automatically attach them to your bug report. You can also add the information after the bug is reported by executing 'apport-collect -p cups BUGNUMBER' where BUGNUMBER is the bug report you want to add information to. - - In releases 8.10, Intrepid Ibex, and older, attach to your bug report the output of the printingbuginfo script located at: https://wiki.ubuntu.com/PrintingBugInfoScript. It manually collects the same information that is collected in the cups apport hook, used by ubuntu-bug and apport-collect above. Starting with Intrepid the '''cupsys''' package has been renamed to '''cups'''. Subsequently, bugs about Intrepid (8.10) and newer releases should be assigned to the '''cups''' package and bug reports about previous releases should be assigned to '''cupsys'''. From noreply at ubuntu.com Sat Jan 18 17:27:18 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sat, 18 Jan 2014 17:27:18 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/HowToTriage=22_by_es2049044?= =?utf-8?q?6e?= Message-ID: <20140118172718.23178.57267@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/HowToTriage" page has been changed by es20490446e: http://wiki.ubuntu.com/Bugs/HowToTriage?action=diff&rev1=157&rev2=158 Comment: Asked confirmed bugs to be tested to be papercuts * Does the bug report describe a valid bug? * Does the bug report contain [[https://wiki.ubuntu.com/Bugs/HowToTriage#Improving_a_bug_report|enough details]]? + * If the bug is a [[One Hundred Papercuts/Papercuts|papercut]], is it [[http://askubuntu.com/questions/231178/how-do-i-report-a-paper-cut|marked as affecting]] the "One Hundred Papercuts" project? - * If necessary, is the bug report [[https://wiki.ubuntu.com/Bugs/HowToTriage#Forwarding_upstream|forwarded upstream]]? + * If bugs for the packaged are managed elsewhere, is the bug report [[https://wiki.ubuntu.com/Bugs/HowToTriage#Forwarding_upstream|forwarded upstream]]? * Is the bug report ready to be worked on by a developer? Only if '''ALL''' of these conditions are satisfied, you can set the status of the bug report to 'Triaged'. To do this: From noreply at ubuntu.com Sat Jan 18 17:35:32 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sat, 18 Jan 2014 17:35:32 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Status=22_by_es20490446e?= Message-ID: <20140118173532.26479.76272@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/Status" page has been changed by es20490446e: http://wiki.ubuntu.com/Bugs/Status?action=diff&rev1=63&rev2=64 Comment: Asked users to only assign bugs just before starting working on them ## page was renamed from BugSquad/ManagingStatus <> + Bug statuses are a reflection of the current state of a bug report. @@ -13, +14 @@ * Bugs are submitted with this status, * They sometimes lack information '''and''' * All of them should be untriaged + * '''Incomplete''': * If you have to ask the reporter questions, set the bug to {{{Incomplete}}} * Ask the submitter to provide any necessary information in a comment, and make sure you subscribe yourself to the bug report so you will get any updates to the bug via e-mail. * <> * If anyone, including you, comments on the bug, the 60 day expiration clock is reset. + * '''Opinion''': * The status 'opinion' means there is a difference of opinion around a particular bug and people are free to continue the discussion, but the project or package maintainers need to move to other work and are considering the issue closed. The idea is that bugs can be marked closed, so developers aren't wasting time on them, but discussion can still be on-going. * This status 'opinion' is considered an experiment, and will be closely monitored. + * '''Invalid''': * This status should be used when the bug report does not contain adequate information to determine whether or not it is a bug even if it is resolved for the reporter * This should also be used if the reported problem is not a bug at all, but for example user error * It should be used conservatively as bugs marked as Invalid no longer show up in default searches * Be sure to triple-check a bug before you invalidate it + * '''Expired''' * This status is similar to Invalid, but is meant specifically for bugs that have been Incomplete for too long. (See above.) * This status is only able to be set by using launchpadlib or the email interface. * Like Invalid bugs, Expired bugs do not show up in default searches. + * '''Confirmed''': * Another reporter has experienced the same bug, this can come in the form of a duplicate bug or a bug comment * {{{Confirmed}}} bugs require confirmation from '''someone other than the original reporter''' * This helps ensure that the bug is applicable to Ubuntu in general, and not a problem with the reporter's system, therefore... * Please don't confirm your own bugs! + * '''Triaged''': * A member of [[UbuntuBugControl]] believes that the report describes a genuine bug in enough detail that a developer could start working on a fix. ''(also see tip below)'' * Use this when you are confident that it should be looked at by a developer '''and''' has enough information * While not a requirement a bug's Ubuntu task status will be Triaged before any upstream forwarding occurs * With bugs about '''linux''' Triaged means that the bug has been tested with the upstream mainline kernel * For process bugs (e.g. [[FreezeExceptionProcess|FFes]] and [[SyncRequestProcess|syncs]]) triaged means the action has been approved by the relevant developers. + * '''In Progress''': - * If '''you''' are working on fixing a bug, set it to {{{In Progress}}} so people know what's going on + * If '''you''' are working on fixing a bug '''right now''', set it to {{{In Progress}}} so people know what's going on - * {{{In Progress}}} bugs should be assigned to the person working on them + * {{{In Progress}}} bugs should be assigned to the person working on them + * '''Fix Committed''': * Ubuntu bug task: the changes are pending and to be uploaded soon (it's what PENDINGUPLOAD was in Bugzilla) * {{{Fix Committed}}} is also used when an updated package exists in a -proposed repository i.e. hardy-proposed * {{{Fix Committed}}} is '''not''' to be used when a patch is attached to a bug * Upstream bug task: the fix is in CVS/SVN/bzr or committed to some place + * '''Fix Released''': * Ubuntu bug task: a fix was uploaded to an official Ubuntu repository * N.B. This '''does not''' include -proposed i.e. hardy-proposed * Please don't hesitate to add a changelog as a comment, so people know in which package version a bug was fixed * If a bug is fixed in the current development release, it is {{{Fix Released}}}. If the bug also [[StableReleaseUpdates | needs to be fixed]] in a stable release, use the "Target to release" link to nominate it for that release. * Upstream bug task: a release tarball was announced and is publicly available + * '''Won't Fix''': * This status is sometimes used when the bug fix is too controversial * It is most often used for bugs with a release target that will not be fixed in that particular release but may be fixed later @@ -65, +76 @@ * moving to Triaged, or WONTFIX * moving ''from'' WONTFIX * targeting to a specific Ubuntu release - + + === Frequently Asked Questions === ''If you have a question, please feel free to ask it by emailing the [[https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad|BugSquad mailing list]] with your question.'' @@ -83, +95 @@ * What is the appropiate bug status for issues caused by faulty hardware? * The appropriate bug status for such issues is "Invalid". + ||{{attachment:IconHelp2.png}}Not yet an [[https://wiki.ubuntu.com/UbuntuBugControl|Ubuntu Bug Control]] member? If you notice a bug having sufficient information and has not yet been set to Triaged, you'll have to ask someone who is to set the bug to ''Triaged'' for you. Paste the bug number in {{{#ubuntu-bugs}}} channel at [[https://wiki.ubuntu.com/FreeNode|FreeNode]] and say you think the bug should be set to 'Triaged' with importance 'Wishlist / Low / Medium / High / Critical' according to [[Bugs/Importance]]. Someone will notice your comment and set it for you, although not necessarily immediately.|| + ---- CategoryBugSquad From es20490446e at gmail.com Sun Jan 19 10:35:55 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Sun, 19 Jan 2014 11:35:55 +0100 Subject: Work-flow prototype Message-ID: <52DBAA8B.6040608@gmail.com> Can you make me a *favour*? *Next time* you wanted to manage some bugs, please give this little baby a *try*; and then some (picky) *feedback*. Have a nice day 🎏 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jack at troop55.net Sun Jan 19 14:18:42 2014 From: jack at troop55.net (Jack Ramsay) Date: Sun, 19 Jan 2014 08:18:42 -0600 Subject: [Papercuts-ninja] Work-flow prototype In-Reply-To: <52DBAA8B.6040608@gmail.com> References: <52DBAA8B.6040608@gmail.com> Message-ID: Good job with that. I would like to suggest one change. Please reverse the order of the steps so that it starts with 1 and ends with 5 with one being on the top and 5 on the bottom. On Jan 19, 2014 4:36 AM, "Alberto Salvia Novella" wrote: > Can you make me a *favour*? > > *Next time* you wanted to manage some bugs, please give this little babya > *try*; and then some (picky) *feedback*. > > Have a nice day 🎏 > > _______________________________________________ > Mailing list: https://launchpad.net/~papercuts-ninja > Post to : papercuts-ninja at lists.launchpad.net > Unsubscribe : https://launchpad.net/~papercuts-ninja > More help : https://help.launchpad.net/ListHelp > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From es20490446e at gmail.com Sun Jan 19 15:36:37 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Sun, 19 Jan 2014 16:36:37 +0100 Subject: [Papercuts-ninja] Work-flow prototype In-Reply-To: References: <52DBAA8B.6040608@gmail.com> Message-ID: <52DBF105.9040300@gmail.com> Since work-flow starts at the latest step, this is done *deliberately*! I'm now drawing a stream map , so you can understand why work-flow has been designed like this. El 19/01/14 15:18, Jack Ramsay escribió: > > Good job with that. I would like to suggest one change. Please reverse > the order of the steps so that it starts with 1 and ends with 5 with > one being on the top and 5 on the bottom. > > On Jan 19, 2014 4:36 AM, "Alberto Salvia Novella" > > wrote: > > Can you make me a *favour*? > > *Next time* you wanted to manage some bugs, please give this > little baby > a > *try*; and then some (picky) *feedback*. > > Have a nice day 🎏 > > _______________________________________________ > Mailing list: https://launchpad.net/~papercuts-ninja > > Post to : papercuts-ninja at lists.launchpad.net > > Unsubscribe : https://launchpad.net/~papercuts-ninja > > More help : https://help.launchpad.net/ListHelp > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at ubuntu.com Sun Jan 19 12:28:14 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 19 Jan 2014 12:28:14 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Status=22_by_es20490446e?= Message-ID: <20140119122814.27943.31850@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/Status" page has been changed by es20490446e: http://wiki.ubuntu.com/Bugs/Status Comment: Redirected to "Bugs/Bug status" New page: Continue to [[Bugs/Bug status]]. From noreply at ubuntu.com Sun Jan 19 12:29:47 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 19 Jan 2014 12:29:47 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Bug_importance=22_by_es2049?= =?utf-8?q?0446e?= Message-ID: <20140119122947.27962.86846@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/Bug importance" page has been changed by es20490446e: http://wiki.ubuntu.com/Bugs/Bug%20importance Comment: Redirected to "Bugs/Bug importances" New page: Continue to [[Bugs/Bug importances]]. From noreply at ubuntu.com Sat Jan 18 19:52:46 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sat, 18 Jan 2014 19:52:46 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Status=22_by_hggdh2?= Message-ID: <20140118195246.7500.56021@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/Status" page has been changed by hggdh2: http://wiki.ubuntu.com/Bugs/Status?action=diff&rev1=64&rev2=65 * '''In Progress''': * If '''you''' are working on fixing a bug '''right now''', set it to {{{In Progress}}} so people know what's going on * {{{In Progress}}} bugs should be assigned to the person working on them + * '''never''' assign a bug to anybody else but you yourself * '''Fix Committed''': * Ubuntu bug task: the changes are pending and to be uploaded soon (it's what PENDINGUPLOAD was in Bugzilla) From noreply at ubuntu.com Sun Jan 19 12:26:03 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 19 Jan 2014 12:26:03 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Importance=22_by_es20490446?= =?utf-8?q?e?= Message-ID: <20140119122603.27943.70350@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/Importance" page has been changed by es20490446e: http://wiki.ubuntu.com/Bugs/Importance?action=diff&rev1=3&rev2=4 Comment: Redirected to "Bugs/Bug importance" - <> + Continue to [[Bugs/Bug importance]]. - Ubuntu uses the following guidelines for assigning importance. The importance of the bug signifies the priority that it should be given by people fixing bugs. - - In order to set the Importance field of a bug in [[Launchpad]], you need to be a member of [[UbuntuBugControl]] either through direct membership or because of your membership in another team. The importance of the bug should be set as soon as possible. - - The importance of a bug report can be modified by clicking on the current Status or Importance, in the yellow line and under the "Affects" column header, which will reveal a sub menu. You can then choose a new importance in the drop down box. - - Here are the meanings of the different importance values: - - * '''Undecided''': The default for new bugs. Also means that there is insufficient information to determine importance. - - * '''Wishlist''': Missing functionality. - * These aren't always bugs, but can be ideas for new features which do not yet exist. - * These can also be requests to have software packaged for Ubuntu. - * If it is non-trivial to implement, it should rather be written as a feature specification, see FeatureSpecifications. - * These can be bugs that affect an experimental extension or non-essential feature of a given package/project. - * Bugs that would only be fixed on a best-effort or outside-contribution basis might also be considered ''wishlist''. - - * '''Low''': Bugs which affect functionality, but to a lesser extent than most bugs, examples are: - * Bugs that have easy [[http://www.merriam-webster.com/dictionary/work-around|work-arounds]] - * Bugs that affect unusual end-user configurations or uncommon hardware - * Bugs that affect a non-essential aspect and limited scope of the application - * Bugs that have a moderate impact on a non-core application - * Cosmetic/usability issues that does not limit the functionality of a non-core application - * Non-ideal default configurations - - * '''Medium''': Most bugs are of medium importance, examples are: - * A bug that has a moderate impact on a core application. - * A bug that has a severe impact on a non-core application. - * A bug which impacts accessibility of a non-core application. - * A usability issue that does not limit the functionality of a core application. - * A problem with a non-essential hardware component (removable network card, camera, webcam, music player, sound card, power management feature, printer, etc.) - * '''High''': A bug which fulfills one of the following criteria: - * Has a severe impact on a small portion of Ubuntu users (estimated) - * Makes a default Ubuntu installation generally unusable for some users - * For example, if the system fails to boot, or X fails to start, on a certain make and model of computer - * A problem with an essential hardware component (disk controller, built-in networking, video card, keyboard, mouse) - * Has a moderate impact on a large portion of Ubuntu users (estimated) - * Prevents the application or any dependencies from functioning correctly at all - * Renders essential features or functionality of the application or dependencies broken or ineffective - * Impacts accessibility of a core application - * '''Critical''': A bug which has a severe impact on a large portion of Ubuntu users - * Causes data corruption - * Crashes the entire operating system - * Renders the system temporarily or permanently unusable - * Severely affects applications beyond the package responsible for the root cause - - ||{{attachment:IconHelp2.png}}If you're not yet an [[https://wiki.ubuntu.com/UbuntuBugControl|Ubuntu Bug Control]] member, you'll have to ask someone who is to do it for you.Paste the bug number in {{{#ubuntu-bugs}}} channel at [[https://wiki.ubuntu.com/FreeNode|FreeNode]] and say you think the bug should be set to importance 'Wishlist / Low / Medium / High / Critical'. Someone will notice your comment and set it for you, although not necessarily immediately.|| - ---- - || '''Footnote:''' || - ||[[http://www.merriam-webster.com/dictionary/work-around|work-around]]:||a plan or method to circumvent a problem ''without'' eliminating it || - ||"core":||A core package can be identified as being part of a task in the apt-cache headers. You can see the apt-cache headers by running `apt-cache show [package]` in a terminal, and looking at the "Task: " field in the output.|| - ||"non-core":||A non-core package can be identified as a package that is not part of a task, and is not in 'main'. You can see the apt-cache headers by running `apt-cache show [package]` in a terminal, and looking at the "Task: " field in the output.|| - ---- - CategoryBugSquad - From noreply at ubuntu.com Sun Jan 19 18:28:54 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 19 Jan 2014 18:28:54 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Bug_statuses=22_by_es204904?= =?utf-8?q?46e?= Message-ID: <20140119182854.8219.87229@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/Bug statuses" page has been changed by es20490446e: http://wiki.ubuntu.com/Bugs/Bug%20statuses?action=diff&rev1=67&rev2=68 Comment: As seen it , this is not true in all cases. * '''In Progress''': * If '''you''' are working on fixing a bug '''right now''', set it to {{{In Progress}}} so people know what's going on * {{{In Progress}}} bugs should be assigned to the person working on them - * '''never''' assign a bug to anybody else but you yourself * '''Fix Committed''': * Ubuntu bug task: the changes are pending and to be uploaded soon (it's what PENDINGUPLOAD was in Bugzilla) From dario.ruellan at gmail.com Mon Jan 20 15:35:03 2014 From: dario.ruellan at gmail.com (Dario Ruellan) Date: Mon, 20 Jan 2014 13:35:03 -0200 Subject: Work-flow prototype In-Reply-To: <52DBAA8B.6040608@gmail.com> References: <52DBAA8B.6040608@gmail.com> Message-ID: Really like the idea. The links to the launchpad lists alone are insanely handy. I'm also wondering about the order. Waiting to read the proper explanation. On Jan 19, 2014 7:36 AM, "Alberto Salvia Novella" wrote: > Can you make me a *favour*? > > *Next time* you wanted to manage some bugs, please give this little babya > *try*; and then some (picky) *feedback*. > > Have a nice day 🎏 > > -- > Ubuntu-quality mailing list > Ubuntu-quality at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at ubuntu.com Wed Jan 22 12:11:18 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Wed, 22 Jan 2014 12:11:18 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingKernelHibernate=22_by_p?= =?utf-8?q?enalvch?= Message-ID: <20140122121118.18981.52089@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingKernelHibernate" page has been changed by penalvch: http://wiki.ubuntu.com/DebuggingKernelHibernate Comment: Created dedicated Hibernate article, as a dedicated suspend article already exists. New page: <> ||<>|| = Triage and Debug of Kernel Hibernate Resume apport bugs = This page is aimed to help you do initial triage and debug of hibernate/resume bugs as reported by apport. This page presents some background information as to how the reporting works, and then will take you through a series of debug steps recommending information and data which will need to be collected. The primary source of reports of hibernate failures arrive via apport. Apport checks at boot time whether there was a hibernate in progress, if we are booting normally then that was never resumed and therefore has failed. This means that the failure may have occurred some time before the report is generated. Bear this in mind when answering the questions below. == Bug Validation == Before gathering information on the bug you could consider the questions in this section which will help weed out false reports and duplicates. === Is this really a failure? === If it is the case where the user has an encrypted swap, hibernation will currently fail. This is a known issue. See below for more information. === Is this a repetition of a previous failure? === If this is another occurrence of a previous reported failure it is best to mark the new bug a duplicate of the first using the Mark Duplicate link on the bug report. == Information Gathering == At a very minimum every hibernate/resume bug should contain the answers the questions in this section before being considered [[https://wiki.ubuntu.com/Bugs/Status|Triaged|target="https://wiki.ubuntu.com/Bugs/Status"]]. === Did the machine break while going into hibernation or waking up? === It is very important to know whether the problem occurs on the way into the hibernation state or on the way out. If the machine never makes it to hibernate, but instead wakes up or powers off incorrectly, that is a hibernate failure. If the machine wakes back up from hibernate but then takes you to the login prompt or crashes after that then it is a resume failure. Please indicate in the bug whether it is a hibernate or wakeup failure and how you determined this. === Is it reproducible? === Is the problem reproducible. If you do say 10 hibernate cycles does the problem occur every time, 1 in 5 etc. Do the symptoms vary at all? Please indicate in the bug how and what you tested. === Did it work before? === Has this hibernate ever worked in the past. If it has which kernel release did it work on? Please indicate in the bug whether it worked, and if so include the contents of /proc/version_signature from that release (or the Ubuntu version number if you do not have it). === Do you end up with flashing Caps Lock light or similar? === If you have a flashing Caps Lock light then very likely you are experiencing a kernel panic. Please indicate that in the bug. === Hibernate specific information === For resume from Hibernate failures, please include the output from the following commands from the boot following the hibernate, this includes information on the search for the resume device etc: 1. {{{dmesg}}} 1. {{{cat /proc/cmdline}}} 1. {{{cat /etc/initramfs-tools/conf.d/resume}}} === Other information === Please include any information as to the circumstances leading up to this failure, anything unusual for example did you see any error messages? = Debugging Hibernate = == Failure due to encrypted swap == [[https://help.ubuntu.com/community/EncryptedHome|https://help.ubuntu.com/community/EncryptedHome|target="https://help.ubuntu.com/community/EncryptedHome"]] Users installing from Ubuntu 9.10 and selecting the Encrypted Home option will automatically have encrypted swap space. Other users may have also ran sudo ecryptfs-setup-swap. It is important to note that Hibernation will work with an encrypted swap but resume will fail. There are ways around this, but they involve choosing a password to use for your encrypted swap and entering that password every time you boot your system, and sharing that password with anyone else that might want to resume the system. This is a known, wishlist [[https://bugs.launchpad.net/ecryptfs/+bug/432785|issue|target="https://bugs.launchpad.net/ecryptfs/+bug/432785"]] that we hope to solve. If you happen to report or triage this type of issue, please tag the bug '''encrypted-swap'''. For triagers, posting the following comment to a bug may help: ||Thank you for taking the time to report this bug and helping to make Ubuntu better. It is currently a known issue that Hibernation will fail to resume due to an encrypted swap. Please refer to https://help.ubuntu.com/community/EncryptedHome for more information. We will tag this bug "encrypted-swap" so that we can track this issue going forward and possibly request additional testing. Thanks in advance for your patience and cooperation. || == Hibernating from text mode == The first step for debugging hibernate is to determine if the issue occurs when triggered using the pm-hibernate command. If possible you should reboot the system with the '''no_console_suspend''' boot parameter. See DebuggingKernelBoot for instructions on how to modify boot parameters. You should then switch to VT1 by pressing Ctrl-Alt-F1. Login at the prompt there and then run the following commands: {{{ setfont /usr/share/consolefonts/Uni1-VGA8.psf.gz sudo pm-hibernate }}} This will select a much smaller font so that you can see more messages should they come out, and then initate the hibernate. To help us investigate the problem please use the following debug test method and report results in the bug. Common method is to take photos of the screen & attach dmesg output to the bug report. == Per sub-system hibernate testing == Again from VT-1 (see above for instructions), first reduce the size of your font with the following commands: {{{ setfont /usr/share/consolefonts/Uni1-VGA8.psf.gz }}} There are three tests listed below: * "devices" test mode in "platform" mode of hibernation * "core" test mode in "platform" mode of hibernation * "core test mode in "reboot" mode of hibernation. The test modes are as follows: * core : test the freezing of processes, suspending of devices, platform global control methods(*), the disabling of nonboot CPUs and suspending of platform/system devices * devices : test the freezing of processes and suspending of devices If you `cat /sys/power/pm_test` and `cat /sys/power/disk` it will list the modes that it supports. Then run the following commands: {{{ $ sudo -i # lsmod > lsmod.output.txt # echo devices > /sys/power/pm_test # echo platform > /sys/power/disk # echo disk > /sys/power/state # dmesg > /tmp/dmesg-devices-platform.txt # echo core > /sys/power/pm_test # echo platform > /sys/power/disk # echo disk > /sys/power/state # dmesg > /tmp/dmesg-core-platform.txt # echo core > /sys/power/pm_test # echo reboot > /sys/power/disk # echo disk > /sys/power/state # dmesg > /tmp/dmesg-core-reboot.txt }}} Please collect the lsmod, full dmesg output files from the failing boot/tests, and attach to the bug report. This includes significant information about the search for the resume device. Please report whether you got any additional messages. Digital photos of the screen are a sensible way to get this into the bug. = Dead, Blank, or Black Screen on Resume = In some cases, a machine can hibernate just fine, and resume without issue, with the exception of waking up to a blacked-out screen. In other words, the computer is running just fine, but the display appears dead. If nothing else in this article solves that issue, or the text above just doesn't apply to your particular setup, one may try disabling Kernel Mode Setting. Edit your grub configuration: {{{ sudo nano /etc/default/grub }}} Find the line reading: {{{ GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" }}} Add {{{nomodeset}}} to the end, inside the quotes: {{{ GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset" }}} Exit from nano and save the file. Make grub aware of the new changes: {{{ update-grub2 }}} When that exits, reboot the computer normally, then test hibernate. This change will persist across reboots unless you explicitly revert it. In some cases, this will also fix another issue where the screen doesn't dim after a period of inactivity like it should, assuming it is otherwise configured to do so in your desktop environment = See also = * [[KernelTeam/SuspendResumeTesting]] ---- CategoryKernel CategoryDebugging From hggdh2 at ubuntu.com Wed Jan 22 14:51:04 2014 From: hggdh2 at ubuntu.com (C de-Avillez) Date: Wed, 22 Jan 2014 08:51:04 -0600 Subject: Some points on the Wiki for Bug(squad|control) Message-ID: <20140122085104.57ce8400@icatu> Hello folks TL;DR -- do not assign bugs to other people. I noticed, a few days ago, some edits on the Bugs/* namespace. In general, good work, and a good consolidation on the multiple (and almost, but not completely identical) pages. There was, though, a edit that I do not agree with. So, to start, let's posit two principles (and I am talking about triaging here): * 1. The documentation about how to deal with bugs in Ubuntu is contained (or pointed to from) in the Wiki, under the Bugs namespace; * 2. NOWHERE else is a good place. Simple principles. The whole idea, after all, is to allow anyone, either starting to help or trying to remember things, a *single* place to go to find information. So, back to the issue at hand. This edit dealt with Bug status and, on reading it, I noticed that a restriction we had in place for quite a long time was not there anymore. This restriction goes as follows: "in general, NEVER assign a bug to somebody else." So I edited the page, and added it back [1]. I was surprised to find, later, a re-edit of the page with this restriction taken out again [2], with a a comment "As seen it , this is not true in all cases." That is not the issue. The issue is one should NOT assign bugs to other people. There are some reasons for this: * I see no problem with assigning bugs to teams (or projects): teams (and projects) usually survive changes. People join, and leave, teams and projects -- their interests changes --, but the teams (and projects) tend to stay. * this has been heavily abused in the past; we were all tired of finding ourselves with a new bug assigned to us *even* when it was not our area/interest/responsibility. * in the same vein, I do not need other people to decide what I have to do *without* contacting me first to see if I agree. This is really, really, bad manners. The restriction was there for a reason. It should be back there (but I am not going to re-edit the page, and start a silly "you are wrong; no YOU are wrong" wiki edit battle). And on the comment ("As seen it , this is not true in all cases."): It does not matter. We may see a series of rules on How To Assign A Bug To Other People in thousands of pages in the web. But, for triaging, the ONLY VALID PLACE is under the Bugs/* namespace, at https://wiki.ubuntu.com. This also show WHY having a single point for triaging (and, in general, for documentation) is a better option. I , personally, cannot understand why would anyone have thought to go to askubuntu.com to ask how to triage a bug. And, worse, why would anyone answer there giving a *different* process, and NOT update the wiki? And this brings another point: these pages provide GENERAL guidance. I certainly do not want to see them grow without limit so that evey single minuscule aspect of triaging can be documented. But I can accept redirection to more specific pages (as long as we do not grow *these* pages without bounds). This is it. It is partially a rant, partially a -- for me -- reasonable request. Cheers, ..C.. [1] https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004438.html [2] https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004436.html -- ab alio expectes alteri quod feceris -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From es20490446e at gmail.com Thu Jan 23 13:20:09 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Thu, 23 Jan 2014 14:20:09 +0100 Subject: Work-flow prototype In-Reply-To: References: <52DBAA8B.6040608@gmail.com> Message-ID: <52E11709.8000103@gmail.com> Here it is the explanation: the Bug Stream Map . On the other hand, I expect the One Hundred Papercuts work-flow to change over time since, rather than details, what's relevant here is the main concept. If you *wanted to help* improving this prototype work-flow but without leaving working in your projects, you can easily reuse the work-flow in your desired project and give feedback. Just open one of the lists and change, in your web-browser's *direction*, "hundredpapercuts" by the desired project's short name (for example, "ubuntu"). https://bugs.launchpad.net/*hundredpapercuts*/+bugs?field.searchtext=... Good day 🌞 El 20/01/14 16:35, Dario Ruellan wrote: > > Really like the idea. The links to the launchpad lists alone are > insanely handy. > > I'm also wondering about the order. Waiting to read the proper > explanation. > > On Jan 19, 2014 7:36 AM, "Alberto Salvia Novella" > > wrote: > > Can you make me a *favour*? > > *Next time* you wanted to manage some bugs, please give this > little baby > a > *try*; and then some (picky) *feedback*. > > Have a nice day 🎏 > > -- > Ubuntu-quality mailing list > Ubuntu-quality at lists.ubuntu.com > > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality > -------------- next part -------------- An HTML attachment was scrubbed... URL: From es20490446e at gmail.com Fri Jan 24 11:15:10 2014 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Fri, 24 Jan 2014 12:15:10 +0100 Subject: Work-flow prototype In-Reply-To: References: <52DBAA8B.6040608@gmail.com> <52E11709.8000103@gmail.com> Message-ID: <52E24B3E.1040004@gmail.com> Work-flow illustrates *both *pile importance and typical bug flow: * Bug *flow* begins with step 1, and ends with step 5. * But pile *importance* is the opposite: the highest importance is for step 5, and the lowest is for step 1. Although people can *freely choose* where to contribute: * They're *clearly shown* where help is more needed. * They're *asked to stop* working when next step is congested. *So* work-flow: * First *liberates congestion* at the end of the flow, so previous steps begin to move too. * Is *visual* how work is flowing, so it's also easy to improve it and choose where to work. * Creates value *constantly* to the Ubuntu OS, so also constant improvements in users' satisfaction and constant returns to the project. * Takes advantage of *every piece of work* done, and makes work much more *easier to understand*. So users will be much more prone to help. * Changes the need to check for errors in the hole report to checking only if previous step was okay, making the process zero-defects and*mistake resistant*. * Since errors in bug handling are not discovered in latter steps, but immediately in next step, this also makes the management to *accelerate*. And for *warranting* this work-flow will respond well to any situation, I designed it testing over the "Ubuntu" project, not the "One Hundred Papercuts" project only. So only step 1 is specific to papercuts management. On the other hand, it's very probable I'll *divide* step 4 (fix a papercut) into more steps. So please subscribe to the page and you'll receive notifications when work-flow is changed. Thank you 😊 El 23/01/14 19:51, Dario Ruellan escribió: > Loved it! > Then, looking again to your 5 steps workflow, you're illustrating the > preferred "priority" for each bug-pile. NOT the actual bug workflow, > but the preferred workflow as a Papercutter, right? > > > On Thu, Jan 23, 2014 at 10:20 AM, Alberto Salvia Novella > > wrote: > > Here it is the explanation: the Bug Stream Map > . > > On the other hand, I expect the One Hundred Papercuts work-flow > to > change over time since, rather than details, what's relevant here > is the main concept. > > If you *wanted to help* improving this prototype work-flow but > without leaving working in your projects, you can easily reuse the > work-flow in your desired project and give feedback. > > Just open one of the lists > and > change, in your web-browser's *direction*, "hundredpapercuts" by > the desired project's short name (for example, "ubuntu"). > > https://bugs.launchpad.net/*hundredpapercuts*/+bugs?field.searchtext=... > > > > Good day 🌞 > > > El 20/01/14 16:35, Dario Ruellan wrote: >> >> Really like the idea. The links to the launchpad lists alone are >> insanely handy. >> >> I'm also wondering about the order. Waiting to read the proper >> explanation. >> >> On Jan 19, 2014 7:36 AM, "Alberto Salvia Novella" >> > wrote: >> >> Can you make me a *favour*? >> >> *Next time* you wanted to manage some bugs, please give this >> little baby >> >> a *try*; and then some (picky) *feedback*. >> >> Have a nice day 🎏 >> >> -- >> Ubuntu-quality mailing list >> Ubuntu-quality at lists.ubuntu.com >> >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality >> > > > > > -- > Darío Ruellan Google Profile > Linkedin > Twitter > > Information Technology Professional > 17CC 5A20 2F75 610F BB0F > 57A2 9D7F 54F3 5705 DDD3 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dario.ruellan at gmail.com Thu Jan 23 18:51:17 2014 From: dario.ruellan at gmail.com (Dario Ruellan) Date: Thu, 23 Jan 2014 16:51:17 -0200 Subject: Work-flow prototype In-Reply-To: <52E11709.8000103@gmail.com> References: <52DBAA8B.6040608@gmail.com> <52E11709.8000103@gmail.com> Message-ID: Loved it! Then, looking again to your 5 steps workflow, you're illustrating the preferred "priority" for each bug-pile. NOT the actual bug workflow, but the preferred workflow as a Papercutter, right? On Thu, Jan 23, 2014 at 10:20 AM, Alberto Salvia Novella < es20490446e at gmail.com> wrote: > Here it is the explanation: the Bug Stream Map > . > > On the other hand, I expect the One Hundred Papercuts work-flowto change over time since, rather than details, what's relevant here is the > main concept. > > If you *wanted to help* improving this prototype work-flow but without > leaving working in your projects, you can easily reuse the work-flow in > your desired project and give feedback. > > Just open one of the listsand change, in your web-browser's > *direction*, "hundredpapercuts" by the desired project's short name (for > example, "ubuntu"). > > https://bugs.launchpad.net/*hundredpapercuts*/+bugs?field.searchtext=... > > > Good day 🌞 > > > El 20/01/14 16:35, Dario Ruellan wrote: > > Really like the idea. The links to the launchpad lists alone are > insanely handy. > > I'm also wondering about the order. Waiting to read the proper explanation. > > On Jan 19, 2014 7:36 AM, "Alberto Salvia Novella" > wrote: > >> Can you make me a *favour*? >> >> *Next time* you wanted to manage some bugs, please give this little babya >> *try*; and then some (picky) *feedback*. >> >> Have a nice day 🎏 >> >> -- >> Ubuntu-quality mailing list >> Ubuntu-quality at lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality >> >> > -- Darío Ruellan [image: Google Profile] [image: Linkedin] [image: Twitter] Information Technology Professional 17CC 5A20 2F75 610F BB0F 57A2 9D7F 54F3 5705 DDD3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at ubuntu.com Mon Jan 27 04:03:27 2014 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Mon, 27 Jan 2014 04:03:27 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Bug_statuses=22_by_es204904?= =?utf-8?q?46e?= Message-ID: <20140127040327.26540.36746@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/Bug statuses" page has been changed by es20490446e: http://wiki.ubuntu.com/Bugs/Bug%20statuses?action=diff&rev1=68&rev2=69 * For process bugs (e.g. [[FreezeExceptionProcess|FFes]] and [[SyncRequestProcess|syncs]]) triaged means the action has been approved by the relevant developers. * '''In Progress''': - * If '''you''' are working on fixing a bug '''right now''', set it to {{{In Progress}}} so people know what's going on - * {{{In Progress}}} bugs should be assigned to the person working on them + * You have assigned the bug '''to you''', and you're going to fix it '''right now''' + * /!\ '''Never''' assign bugs to others + * /!\ If there has been an assignee for more than six months without a fix or response, unasign him and revert this bug status * '''Fix Committed''': * Ubuntu bug task: the changes are pending and to be uploaded soon (it's what PENDINGUPLOAD was in Bugzilla)