ubuntu-bugcontrol team mailing list archive

[Dario Ruellan <dario.ruellan@xxxxxxxxx>]

Something I'm missing on those tutorials is the recommendation for search
for updates before reporting the bug, just in case the problem is already
fixed.

Seem important for me, but I like to hear a second opinion about it.

On May 29, 2017 10:50 PM, "C de-Avillez" <hggdh2@xxxxxxxxxx> wrote:

> On Sun, 28 May 2017 16:54:45 +0200
> Alberto Salvia Novella <es20490446e@xxxxxxxxx> wrote:
>
> > About:
> > (https://help.ubuntu.com/community/ReportingBugs)
> > (https://wiki.ubuntu.com/es20490446e/Reporting%20bugs)
>
> OK, let's get thru the proposed page.
>
> I will be copying text from the proposed Reporting Bugs so that I can
> comment. The version I am using is #32, timestamped 2017-05-27 22:38:52.
>
> Text copied will have the usual "> " we see on replies (well, at least
> *I* see on my text emails. I do not know what/how it is shown on
> HTML/richText).
>
> * 1. Etiquette
>
> > If you care about an Ubuntu release not having bugs, test the daily
> >  image five months before launch. So developers have time to fix it.
>
> Why 5 months before? Our release cycle is *still* 6 months. If we test
> an image 5 months before release, we will be testing pre-alpha code.
>
> * how are people -- non-technical people -- going to test it?
>   Something that is, 5 months before release, pre-alpha?
> * should they only test the code as is 5 months before release?
>
> > If writing more doesn't make a tangible difference, write less.
>
> We need context. If fact, the sentence above is a good example of why
> writing *less* does not always help.
>
> > If you have any doubt, you can ask any time.
>
> I absolutely agree. 100%. All for it. Always.
>
> But...
>
> My issue here is the word "ask", above, is a link to mailing to the
> ubuntu-quality ML. Nothing else. But the ubuntu-quality mailing list is
> NOT the only resource available for people in doubt. There are also:
>
> * IRC
> * The Ubuntu fora (https://ubuntuforums.org)
> * AskUbuntu (https://askubuntu.com/)
> * the answers section on Launchpad (https://answers.launchpad.net/)
> * the ubuntu-users mailing list
> * the Ubuntu documentation (https://help.ubuntu.com/)
> * and MANY other mailing lists.
>
> To limit to ONE source for answers really does not help. At all. And it
> is not even the most important source for bugs/issues/support.
>
> 2. Not Bugs
>
> > Reporting misspells
>
> But a misspell *is* a bug. Why wouldn't a mispell be reported?
>
> 3. Reporting windowed aplications
>
> > In the Terminal application enter:
> >
> > ubuntu-bug -w
>
> Ah, OK. And then this ubuntu-bug thingie will magically find the bug I
> want to report, right? Oh, it will not? what should I do then?
>
> 4. Reporting non windowed applications
>
> > 1. Using the Synaptic application and the list of common packages,
> > determine which software package is the most likely to be affected.
>
> But synaptic is no longer installed by default. How is a casual user
> going to *know* that, and how would this casual user get synaptic
> installed? Are there other options? What are they?
>
> 5. Reporting unusable systems
>
> Now we have, as far as I am concerned, a real issue. As I have already
> stated, we do not simply need more bugs, we need *good*, *workable*,
> bugs. Our experience with free bug entry was horrible. many of the bugs
> entered were unworkable. This was why the free bug entry was removed
> from view.
>
> -x-x-x-x-x-x-x-x-
>
> This is one reason of why reporting bugs is so complicated. It is not
> *easy* to report a bug. Keep in mind that a bug report is a *technical*
> report of a software defect.
>
> If one does not know what a bug is (hint: a bug is a defect in a
> program/package), why should one be able to enter *anything* as a bug?
>
> If one does not know if the bad experience just had is, or is not, a
> bug, then one would be better served by going to the community support
> areas I pointed above. If necessary, after being helped by somebody else
> in the community -- and if determined to be a bug -- then a bug may be
> opened. But know, at least, we have a good chance of knowing the correct
> package name, and  other important details to be reported.
>
> Cheers,
>
> ..C..
>
>
>
>
>
> --
> Ubuntu-quality mailing list
> Ubuntu-quality@xxxxxxxxxxxxxxxx
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/ubuntu-quality
>
>