Re: Ubuntu-quality Digest, Vol 78, Issue 6
El 08/04/14 09:08, Aditya Rohilla escribió: I am new to open source, as well as to ubuntu.. Can anyone plz help and tell me, how can I contribute to it? Just have a look at https://wiki.ubuntu.com/QATeam/Roles and choose what you'll like the most ;) We also have a project specially designed for newcomers: https://launchpad.net/hundredpapercuts And if you need some assistance in the process, you can easily contact us: https://wiki.ubuntu.com/QATeam/Contact Enjoy! -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Bug importances - Suggestion for improvement
To https://wiki.ubuntu.com/Bugs/Bug%20importances, I would suggest adding a new criteria under the critical importance (or something like this): It simplifies software contents, bug fixing or development So, although not doing this apparently hasn't got any critical consequences, it already eliminates the main sources of waste. That is excess of inventories: dozens of bugs already fixed in upgrades that are asked to be performed, generally in special types of bugs (https://wiki.ubuntu.com/Bugs/Bug%20triage#Special_types_of_bugs) In fact, eliminating excess of inventory first is a general accepted recommendation in many productivity philosophies: - Just in Time (https://en.wikipedia.org/wiki/Just_in_time_%28business%29) - 5S (https://en.wikipedia.org/wiki/5S_%28methodology%29#1._Seiri) - Lean Six Sigma (https://en.wikipedia.org/wiki/Lean_six_sigma) - The Seven Habits of Highly Effective People (http://hdbizblog.com/blog/2008/04/28/sharpen-the-saw-the-7th-habit-of-highly-effective-people/) The amount of bugs of this kind are a few and working on them first can save lot of time in the medium term, while also making the fixing of critical bugs more speedy. So, what do you think? -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Bug importances - Suggestion for improvement
I disagree with you here. The Critical priority, in my opinion, should apply only to bugs which cause critical loss of functionality, either a crash or something in core not working and causing a cascade of problems in other applications, or super severe exploits, or some other, truly critical bug, which absolutely demands developers' full attention immediately. Why would we want to put a simplifies the packaging or other simplifies X (where X is anything) bugs as Critical priority, which basically is a screaming red alert to devs for their respective packages? -- Thomas LP: ~teward *Sent from my iPhone. Please excuse any typos, as they are likely to happen by accident.* On Apr 8, 2014, at 8:27, Alberto Salvia Novella es204904...@gmail.com wrote: To https://wiki.ubuntu.com/Bugs/Bug%20importances, I would suggest adding a new criteria under the critical importance (or something like this): It simplifies software contents, bug fixing or development So, although not doing this apparently hasn't got any critical consequences, it already eliminates the main sources of waste. That is excess of inventories: dozens of bugs already fixed in upgrades that are asked to be performed, generally in special types of bugs (https://wiki.ubuntu.com/Bugs/Bug%20triage#Special_types_of_bugs) In fact, eliminating excess of inventory first is a general accepted recommendation in many productivity philosophies: - Just in Time (https://en.wikipedia.org/wiki/Just_in_time_%28business%29) - 5S (https://en.wikipedia.org/wiki/5S_%28methodology%29#1._Seiri) - Lean Six Sigma (https://en.wikipedia.org/wiki/Lean_six_sigma) - The Seven Habits of Highly Effective People (http://hdbizblog.com/blog/2008/04/28/sharpen-the-saw-the-7th-habit-of-highly-effective-people/) The amount of bugs of this kind are a few and working on them first can save lot of time in the medium term, while also making the fixing of critical bugs more speedy. So, what do you think? -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Ubuntu-quality Digest, Vol 78, Issue 6
Thankyou so much I will have a look at these, and let you know what excites me the most. On Apr 8, 2014 5:31 PM, Alberto Salvia Novella es204904...@gmail.com wrote: El 08/04/14 09:08, Aditya Rohilla escribió: I am new to open source, as well as to ubuntu.. Can anyone plz help and tell me, how can I contribute to it? Just have a look at https://wiki.ubuntu.com/QATeam/Roles and choose what you'll like the most ;) We also have a project specially designed for newcomers: https://launchpad.net/hundredpapercuts And if you need some assistance in the process, you can easily contact us: https://wiki.ubuntu.com/QATeam/Contact Enjoy! -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Bug importances - Suggestion for improvement
El 08/04/14 14:51, Thomas Ward escribió: Why would we want to put a simplifies the packaging or other simplifies X (where X is anything) bugs as Critical priority, which basically is a screaming red alert to devs for their respective packages? With simplify I mean to eliminate, clean or organize content of development or bug management: - Merge - Sync - Remove - Promote - Demote The reason for this kind of bugs to be set critical is developers to start working in this special bugs, which potentially can save tons of coding in fixes that are already upstream and throw out which work is real. Moreover these bugs are bytesize and there are only a few of them. -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Bug importances - Suggestion for improvement
El 08/04/14 20:10, C de-Avillez escribió: Bug management does not apply to workflow bugs. They fact developers have to look at this reports first stays untouched. -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Bug importances - Suggestion for improvement
On Tue, Apr 8, 2014 at 1:45 PM, Alberto Salvia Novella es204904...@gmail.com wrote: El 08/04/14 20:10, C de-Avillez escribió: Bug management does not apply to workflow bugs. They fact developers have to look at this reports first stays untouched. Sorry, I do not understand what you said above. Can you please rephrase? -- ..hggdh.. -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Bug importances - Suggestion for improvement
Workflow bugs may be seen by the developers, but I've seen a lot of devs just ignore these and let the workflow run, especially on universe packages. These bugs are usually relatively-quickly intercepted during the development cycle for packages in main, and are handled, from what I've seen. For Universe, they happen whenever it's gotten to, last I checked. Workflow bugs aren't governed by our bug triage policy. If developers here on packages in Ubuntu (and incidentally Launchpad) are unaware of what workflow bugs are, they should read the section of the documentation on special workflow bugs. In the How to Triage guide [1], even, there's a section labeled Special Types of Bugs [2], which says that unless you know what you're doing, you shouldn't touch those bugs. Status included. I think that still applies here, if developers of a given package are unaware of this, then we can easily make a note that this is a workflow process bug, not necessarily something they *need* to immediately look at, especially since not all upstreams actually do much with the workflow process here. That's my opinion on this. Let's move on to actually fixing bugs, not dealing with how we set the importance on special bugs, of which our bug triage rules don't really apply in the same way (if at all, case in point merge requests, sync requests, security bugs (which have slightly different policies), etc.). -- Thomas LP: ~teward On Tue, Apr 8, 2014 at 2:45 PM, Alberto Salvia Novella es204904...@gmail.com wrote: El 08/04/14 20:10, C de-Avillez escribió: Bug management does not apply to workflow bugs. They fact developers have to look at this reports first stays untouched. -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/ mailman/listinfo/ubuntu-quality -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
