Fwd: Ubuntu-quality post from php4...@gmail.com requires approval

[C de-Avillez]

I mistakenly deleted the email below from the moderation queue.
Fortunately I still had the original moderation notice. As such, I am
sending this over to the ML.

@Php4fan -- I apologise. I am not sure if there was more to your
email, so please verify.

..hggdh..

-- Forwarded message --
From: php fan 
To: Ubuntu Quality Team 
Cc:
Bcc:
Date: Tue, 21 Jul 2020 19:20:37 +0200
Subject: URGENT: I need a workaround or fix to the broken fan speed control
Hello,

As was reported years ago, there's a bug somewhere in Ubuntu that
prevents the cooling fan to spin at the needed speed.
The details are at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1697567 but in a
nutshell, the proof that something is wrong is that (a) my CPU gets so
hot that it switches itself off, and (b) the fan doesn't get even
remotely close to its maximum speed (or half that) when that happens.

(a) and (b) are incompatible on a system that works, regardless of how
bad a condition the fan may be in. If (a) happens, then the fan must
by definition be spinning at its highest possible speed. If (b) is
true (i.e. the fan is spinning at a much lower spin), then the
temperature must be well below the safety value, otherwise the fan
would be spinning faster in an attempt to cool it down.

Recently the situation got worse, in two ways:
1. my CPU just gets hotter and it happens more often that it gets too
hot. This *might* be due not to something having changed in how the
software controls the speed: it could be that my fan has got more
dirty and less efficient,  and since the OS's way of controlling it
fails to react properly, in the exact same way it always did, the
situation is worse. But also:
2. when I reboot, it used to be the case that while Grub displayed the
boot menu, the fan would start to spin much faster (proving that it is
capable to, and that it needed to), and only later during the boot
would it slow down (presumably because the broken speed control would
kick in). Now, it spins too slowly even during the boot menu. The only
explanation I can find for it is that the same broken speed control
(or a different one equally or more broken) has now been implemented
in Grub too. This means that I no longer even have at my disposal the
last-resort pathetic workaround of restarting the machine and leaving
it with the boot menu open to cool down for a few minutes before I
resume working.

By the way I recently upgraded from 16.04 to 20.04 and this hasn't
been fixed. I observed the worsening in (1) before I upgraded (so
either it has nothing to do with changes in software, or it was due to
a software update in 16.04). On the other hand, the change (2) has
happened while I was already using 20.04. I think that happened when I
installed KDE Plasma Desktop, which installed something grub-related.

Since nobody seems to care to fix a bug that has been known to brick
computers for years, I urgently need a workaround to manually force my
fan to spin faster.

A. Is there a tool to manually control the fan speed?
B. The speed control algorithm seems to be (the observed behavior
suggests) a stupid temperature->speed map with no feedback  or
calibration whatsoever. Is this map stored somewhere in some file that
I can edit, so I can try to simply increase the values of speed or
decrease the threshold temperatures? Or is it hard-coded?

-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: URGENT completely crippling regression

[C de-Avillez]

On Fri, May 31, 2019 at 10:52 PM Teo Tei  wrote:

>> I started reading the bug, and completely lost interest when I notice
>> the tone used in the description.
>>
>> --
>
>
> How is that? Seriously, please explain it to me because I don't understand 
> it, and it fascinates me every single time (yeah, because it's not the first 
> time).

No, it is not the first time, We have been thru that dance a few times
before. And, most of the times, you would end up moderated. And... You
would register yourself again to the mailing list under a slightly
different name. And keep on the same behaviour. Which is, everywhere,
called "mod-evading." Which is usually frowned upon.

As you were told many times, at Ubuntu we have a Code of Conduct [1].
Being nice to others is expected; if you cannot be nice, at least be
neutral.

> How exactly does the tone of a particular person describing an issue affect 
> how much you care about the issue, which obviously does not affect only that 
> person but potentially every single user?

See the Code of Conduct [1].

> I really don't get it. I understand you can care about a particular issue 
> more or less based on how much it affects you, for example, or how serious 
> you consider it to be for users in general, or how likely you are to be able 
> to contribute  yourself to fixing it, or simply your personal interests and 
> tastes.

Absolutely correct, and I absolutely accept that.

> And I also understand how you can find the tone of a user complaining about 
> an issue more or less appropiate, agreeable, or acceptable.

Yes. You KNOW that. Again, apart from any other interaction you had
with Ubuntu, you know because you have been told many times about it.

> But I don't see how on earth one thing would affect the other. I try to put 
> myself in your position: I imagine I am reading about some malfunctioning of 
> some software which I'm generally interested in in some way (because I often 
> contribute to it, or because I'm a user myself, or for whatever reason, 
> otherwise I wouldn't be reading a bug report in the first place). Now I 
> imagine the report is written in a way  I don't like (maybe I find it 
> offensive or something, I don't know,  just guessing), let's even say I'm 
> getting the impression that the person writing the bug report is a total 
> ***hole, I hate that guy, he even *deserves* to be suffering from the issue! 
> However, I don't see how that would cause me to care any less about the issue 
> itself. Personally, if anything, it could only make me care more, given it 
> would demonstrate how frustrating it can be to users suffering from it. Or 
> not, but in the worst case, it would make no difference whatsoever.

Why would I help somebody that, from the start, is aggressive (as far
as I understand it)? My experience is it *rarely* ends in a good way.
And,  a long time ago, I decided I did not need to deal with these
situations.

> I would really love to learn about your thought process, understand this 
> connection between how a bug report is written (specifically the "tone": not 
> even the quality or quantity of the information contained in it) and how 
> anybody should care about that bug. Again, it fascinates me. It's a mystery.

It is a simple thought process. I am a volunteer. I help on Ubuntu
because I like Ubuntu. And I have been thru many other distros in all
the years I have used Linux. Ubuntu was the *first* one (apart from
all other merits) that actually stated it would be good for all if
everybody were to be nice (I accept neutral) to each other. For the
record, while I was actually working as tech support, whenever we
received a bug report like yours we would *immediately* report it to
the OP's management. This was an order from our top management.

So I am picky. I can understand if an OP slips and gets aggressive
once, perhaps twice. But you have a LONG story of being aggressive
from start, and keeping on it. So I allow myself to completely
disregard you *while* you keep off the CoC.

*You* think you can disrespect others (and the whole idea of the CoC).
*I* think I can disregard folks like you.

It is not a mystery. People are different. For you, being not nice
seems to be a way of living. For me, being nice also seems to be a way
of living. Also, just as an aside, you might get a better response to
your bug if re-word it in a nice way. There are many ways to state you
have unhappy. NONE need to be aggressive, in tone or words.

I note, just for the record, that I *am* answering you. But only
because you kept a civil discourse.

Cheers,

..C..

[1] https://www.ubuntu.com/community/code-of-conduct


-- 
..hggdh..

-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: URGENT completely crippling regression

[C de-Avillez]

On Fri, May 31, 2019 at 7:30 PM Teo Tei  wrote:
>
> Hello,
>
> Please see this bug report, this makes many basic applications in Ubuntu
> completely unusable:
>
> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1831280
>
> I haven't restarted my computer yet, I don't know if the issue would
> disappear after a reboot, and reappear only sporadically, or not.
>
> Either way, it needs very urgent attention.
>
> It must have been introduced by some recent update (again, unless it's
> something that happens randomly and sporadically and by mere chance I'm hit
> now for the first time).

I started reading the bug, and completely lost interest when I notice
the tone used in the description.

-- 
..hggdh..

-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Unable to report bug

[C de-Avillez]

On Wed, Dec 5, 2018 at 10:30 AM C de-Avillez  wrote:



> We know they are soft links because of the first character in the
> permissions field: 'l'. You
> now 'cd 06-ISO'. Since '06-ISO' is a soft link, your CWD is now moved
> to the *actual* directory
> pointed to by the soft link: /data/LIBRARY/06-ISO.
>
> And, from now on, any directory command will be based on the CWD,
> which is /data/LIBRARY/06-ISO, *not*
> ~/Downloads/06-ISO.
>
> So, if this is what you were trying to report, it is working as expected.

Erm...

confused myself.

You are mixing 'cd' (which is a shell command) with 'ls' (which is
part of coreutils).

For example:

I created, under ~, two directories: ~/test, and ~/test/test1:
cerdea@piatam:~$ ls -la test
total 12
drwxr-xr-x  3 cerdea cerdea 4096 Dec  5 10:42 ./
drwxr-xr-x 69 cerdea cerdea 4096 Dec  5 11:04 ../
drwxrwxr-x  2 cerdea cerdea 4096 Dec  5 10:43 test1/

I also created a soft link ~/test-sl -> test/test1:

cerdea@piatam:~$ ls -l | grep test-sl
lrwxrwxrwx   1 cerdea cerdea  10 Dec  5 10:44 test-sl -> test/test1/

Now, under ~, I cd to test-sl:

cerdea@piatam:~$ cd test-sl
cerdea@piatam:~/test-sl$ pwd
/home/cerdea/test-sl
cerdea@piatam:~/test-sl$ echo $OLDPWD
/home/cerdea

So bash knows I am under a soft-linked directory, and shows me that.

Now I 'ls ..':

cerdea@piatam:~/test-sl$ ls ..
test1/

And ~/test1 is shown -- correctly, since 'ls' uses the *actual* path.

But bash, being helpful, still use $OLDPWD to 'cd -' or 'cd ..':

cerdea@piatam:~/test-sl$ cd -
/home/cerdea
cerdea@piatam:~$


--
..hggdh..

-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Unable to report bug

[C de-Avillez]

On Wed, Dec 5, 2018 at 9:34 AM bernard  wrote:
>
> Hi Brian,
>
> Thanks for your reply. I've been using Ubuntu for years, and it's an OS
> i like very much.
>
> I'm not attempting to report a bug about ubuntu-bug but a bug with
> ubuntu-bug. What i can't do without a core dump or crash report ...
>
> You'll find attached a 'script' file that show how Ubuntu behave in a
> particular situation and that, by comparison, do not react as the other
> OSes i'm actually working on.
>
> Feel free to transmit this or not to your team.
>
> Any further questions welcome.

Hi Bernard,

First of all, you *can* use ubuntu-bug without a crash report. As
Brian pointed out, you can use:

   ubuntu-bug 

where  is the package you want to report on. In this case, I
am *guessing*
you want to complain about 'ls's behaviour, so you would run:

ubuntu-bug coreutils

Since 'ls' is part of the coreutils package.

Now, for the script file you attached: you have, under ~/Downloads, a
series of soft links
to directories under /data. This can be seen here:

bernard@linbox:~/Downloads$ ls -l

Also, your CWD is ~/Downloads.

total 875452
lrwxrwxrwx  1 bernard bernard26 déc.   2 00:53  00-ANIMATION
-> /data/LIBRARY/09-ANIMATION
lrwxrwxrwx  1 bernard bernard22 déc.   1 23:32  01-BOOKS ->
/data/LIBRARY/01-BOOKS
lrwxrwxrwx  1 bernard bernard19 déc.   2 00:50  02-BD ->
/data/LIBRARY/08-BD
lrwxrwxrwx  1 bernard bernard23 déc.   2 00:23  03-MUSIC ->
/data/LIBRARY/03-MUSIC/
lrwxrwxrwx  1 bernard bernard23 déc.   1 23:51  04-FILMS ->
/data/LIBRARY/04-FILMS/
lrwxrwxrwx  1 bernard bernard23 déc.   2 02:38  05-UNREAD ->
/data/LIBRARY/10-UNREAD
lrwxrwxrwx  1 bernard bernard21 déc.   2 02:37  06-ISO ->
/data/LIBRARY/06-ISO/

We know they are soft links because of the first character in the
permissions field: 'l'. You
now 'cd 06-ISO'. Since '06-ISO' is a soft link, your CWD is now moved
to the *actual* directory
pointed to by the soft link: /data/LIBRARY/06-ISO.

And, from now on, any directory command will be based on the CWD,
which is /data/LIBRARY/06-ISO, *not*
~/Downloads/06-ISO.

So, if this is what you were trying to report, it is working as expected.

Cheers,

-- 
..hggdh..

-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: I'm stopping contributing

[C de-Avillez]

On Tue, 6 Jun 2017 21:57:55 +0200
Alberto Salvia Novella  wrote:

> Speaking about the Roman's king, I have just received this email from
> a familiar which I have installed Ubuntu:
> 
> Cousin:
>  > It gets worse every time, especially at start-up, it hangs and
>  > needs to restart.  
> 
> 
> Other mentions in the latests two months:
> 
> Father:
>  > It usually hangs at start-up, and mouse stops working from time to
>  > time.  
> 
> Friend:
>  > Ubuntu was no longer booting up. I needed it for my end of career
>  > work, so you know what I did? Removed it and installed Windows
>  > 10.  

So would you open a bug with the following description:

"it gets worse every time, specially at start-up, it hangs and needs to
restart"

What are we supposed to do with this bug?

> So it seems that all of these happens nearly all of the time:
> (https://askubuntu.com/questions/760934/graphics-issues-after-while-installing-ubuntu-16-04-16-10-with-nvidia-graphics)

Ah. So these are all symptoms of a nVidia driver issue? I agree this is
a bug. The problem -- specifically for nVidia -- is: who fixes it? It is
closed source, so we cannot; or it depends (as what happened on 16.04
release) on a future kernel support, at the time to be coded, tested,
and released (perhaps some of us would be able to code it in; I am not,
though.

I also do not know if this has been solved, I left nVida a
long time ago because I was tired of their crappy coding and
continuous bugs.

I am pretty sure there are already many nVidia bugs recorded in LP,
still open. I wonder what having more of them (supposing all new bugs
are clearly set against nVidia, not against Ubuntu, or other wrong
package) would help.

> Root cause: nobody is reporting bugs and nobody is triaging them, as 
> it's too hard to read the manuals.

Wrong root cause, but let's move on.

So, by all means, let's re-write the Reporting Bugs wiki and related
pages.

But keep in mind my point, throughout this series of email threads: it
does NOT help triagers and maintainers to have a LOT of badly-reported
bugs. We need *good quality* bugs. 

[A good start on re-writing, perhaps, would be adding a list of
high-impact bugs, that people can look at and add a "me too" if their
bug fits). For whatever definition of "high-impact".]

But what you proposed is not a good re-write, as far as I can see it.
You proposed to simplify to such a point the reporting bugs could as
well be written as "go to LP and write whatever you want". There. One
single line (if you replace "LP" by the correct link). Which is BAD bug
reporting, but so what?

> And people won't allow the needed 
> change because of:
> 
> (https://plus.google.com/+AlbertoSalviaNovella/posts/6fmD4E2vKfP)

[Now I am completely lost. What does political correctness have to do
with good reporting of bugs? Anyway.]

For the record, "people won't allow the needed change" is wrong in a
few points:

* you have the power to re-write the wiki. Other people *also* have the
  power to undo what they perceive as wrong. The same right you have
  others have. If this escalates, some with more power will take
  whatever actions deemed necessary to stop the write/re-write cycle.

* or, perhaps, you want those that did not agree with you *NOT* to be
  able to do so?

* nobody prohibited you on working on the re-write. Many did not agree
  with it, I grant. But you were NOT, by a long shot, prohibited from
  giving a new view.

* what once happened was you changing a wiki page *without* a proposal,
  and doing it in a way that some that were working with it disagreed.
  This was, indeed, *your* fault: you do not, unilaterally, change
  something that is used by a lot of people. You *propose* your
  changes, and reach a consensus.

* but you do not seem to want a consensus. You want *your* way, or the
  highway. This is not how a community, be it a democracy or
  meritocracy, works. This is, on the other hand, how dictatorships
  work.

So what you have experienced is /not/ people not allowing the "needed
change", it was people -- community members just like you -- disagreeing
with your proposed changes.

Let me be clear on this: I *know* the Reporting Bugs is a mess. I
*agree* the pages have to be re-organised, cleaned up, re-written. I
*disagree* with your approach, for reasons already discussed ad nauseam.

But this is *my* view. OK, I agree it is biased by my years of
technical support. But it is still my view. Personal. I do not speak,
formally,  for the project -- I have no authority to do so. But I *do*
speak in the community based on my personal interest in bugs and
triaging. After all, I am a member of this community -- which, by the
way, would be as true if I were not to be an official Ubuntu member(as
you also are).

Cheers,

..C..




pgpwwriYZ4rpn.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 

Re: [Ubuntu-bugcontrol] I have written a draft for the Reporting Bugs guide

[C de-Avillez]

On Tue, 30 May 2017 20:33:34 +0200
Alberto Salvia Novella  wrote:

> Sorry but I spend an hour writing an answer to these emails, but even 
> then I ended with something extra long that I think nobody will read
> or understand.

Writing is easy. Anybody can write. But *good* writing is difficult. We
have to try. We have to re-work what was written. We have to change
sequence of ideas. We have, at the worst, to consider that all we had
written bad enough to be thrown away, and re-start. And, if we publish,
we have to be willing to read the critics, and try to improve.

But, if we do not try, and persevere, we will never be able to write
something that can be understood. 

I have already, in a previous email in this thread, given you some
ideas on how to write. Try them. Research for other tips. Try them.
Listen to critics (which, usually, will be a written text). Respond in
writing.

> In fact that's what usually happens when I answer in text. On the
> other hand when I use video in a couple of minutes I'm usually done.

But you are *writing* a wiki page. How will you be able to write it if
you cannot justify your proposal in writing (H/T to Gunnar
Hjalmarsson, good point).

[in fact the hat tip above comes to show that *others* can have good
insights. I am not infallible. Nobody is.]

> I will simply keep those as short as possible. And instead of making
> a monologue, with all the information, I would simulate an actual 
> conversation. Usually with 10-20 seconds answers.
> 
> (https://youtu.be/L45EqUl2q4M)

I will not listen to it. If you can *talk* your points, you can as well
*listen* to your own speech, and transcribe it. Then you put the
transcription in an email and, lo and behold, you have written text.

Cheers,

..C..


pgpFiPabQ4NBF.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: [Ubuntu-bugcontrol] I have written a draft for the Reporting Bugs guide

[C de-Avillez]

On Sun, 28 May 2017 16:54:45 +0200
Alberto Salvia Novella  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..






pgpAPHu5EJRwL.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: [Ubuntu-bugcontrol] I have written a draft for the Reporting Bugs guide

[C de-Avillez]

On Sun, 28 May 2017 16:54:45 +0200
Alberto Salvia Novella  wrote:

NB: I have not yet *read* the new proposal. I am just discussing the
approach here.

> About:
> (https://help.ubuntu.com/community/ReportingBugs)
> (https://wiki.ubuntu.com/es20490446e/Reporting%20bugs)
> 
> Sorry, but I'm absolutely convinced that the latest draft I've
> written is really what's needed.

Alberto, during this thread you were asked why would you want to have a
discussion of the changes in private conversations. You stated
something suggesting "I can then submit something more complete [to be
discussed by the community].

Now you come back absolutely convinced whatever you did (keep in mind I
did not read it yet, I am just discussing form and approach) is THE
ANSWER.

I do not know if it is or not. But I can say you are approaching it in
a less than ideal way.

> The sections clearly reflect every use case, and they are organised
> in a logical way. The writing style is conversational and easy to
> understand.
 
> The content is exactly what the user is looking for, and adding 
> something else won't ease their job nor change their behaviour. If 
> there's something useful to somebody else, it should go somewhere
> else.

Just a question: and what it is we -- the community of bug
triagers/solvers/developers are looking for? Are our requirements
fulfilled? Remember, there are *always* [at least] two sides involved.

You "exactly what the user is looking for". Great. What is it we --
maintainers/developers  -- are looking for? Are our requirements/needs
addressed? 

> The imagery suggests the page is easygoing, softens it, and makes it 
> more memorable. There's nothing impolite about it, neither gives the 
> wrong image of Ubuntu.

> The community isn't targeted to super professionals but to all kinds
> of people, many of which are student in their teens.

> So either you take it as it is, or you leave what you have. I will
> wait till Sunday the 4th, to let you decide yourselves. I will take
> that resolution as hard fact on what to expect in the future.

The above sounds like "either you pay me the ransom, or I will kill the
hostages." A perfect example of ultimatum.

> I'm looking forward to work only with people who are in complete 
> sympathy and harmony with my purpose, which is "easy and
> straightforward over correct".

This is the wrong approach. This is the absolutely WRONG approach.

What you are saying here is equivalent to "I am looking forward to
work only with people that /think like I think/."

This will not happen. This will *never* happen. Everybody has a
(perhaps just slightly) different approach/view/way of
coping/interest/whatever.  

Even more importantly, if I am surrounded only with people that think
like I think, all I have is reinforcing of my own bias and prejudices.

Yes, there will also be reinforcing of the *good* ideas, but there is
no way to KNOW if they are good or not, since nobody in the group will
have a different view.

> Thank you.

and thank you.

..C..


pgp7La6H4WFTN.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: I have written a draft for the Reporting Bugs guide

[C de-Avillez]

On Fri, 12 May 2017 11:57:33 +0200
Alberto Salvia Novella  wrote:

> Persons could have lot of experience, but the question is "would the 
> current guide allow most people to report bugs?"

This is a more difficult question to answer.

Let's try to define a few terms, first of all. I will be talking, here,
mostly about software.

* a BUG is a *defect*. It may be expressed in code, documentation,
  spelling, wrong output, whatever. But it is a *defect*.

Defects (or bugs) come in many forms. It may be as clear as a segfault
in a program, or as obscure as a wrong sentence in a manual (or
occasional, "magical" issues).

* a DEFECT is defined, in the Cambridge dictionary, as "something that
  is lacking or that is not exactly right in someone or something".

This is important, even being vague: "not exactly right" is as vague as
possible, but it passes the idea.

* a bug is EXPRESSED when we notice the defect. This does not mean the
  bug did not exist until being expressed. The bug *was* there for a
  while (at least), but we did not know about it.

* a bug REPORT is a *technical* description of the defect.

Notice that I stress "technical". Maintainers and developers will have
to read the bug reports, and zero in the issue. So, vague bugs reports
Are Not Good(TM). They waste our time. Usually maintainers/developers
will not waste time with a visibly vague bug report.

The above, I think, is pretty much what anyone would expect. Now...

* if there is no defect, then there is no bug.

This means that issues like "I do not know how to print a file" are
*NOT* bugs -- a priori. These are typical "customer support" questions.
"I do not know how to " is NOT a bug. It is ignorance. It has
NO place in a bug control system. Now, it might happen that someone may
not know how to  because the manual is incomplete... THEN the
incomplete manual *IS* a bug.

* LP/bugs is a repository of *bugs*. It is NOT a repository of customer
  questions.

So, with the above in mind. 

We have been trying to move customers to open BUGS using ubuntu-bug and
similar. There is a reason for that: we were tired of having bugs with
NO useful data ("I cannot boot", as the description and title of the
bug, for example). This means that we *knowingly* made it more
difficult for a casual user to directly open a bug in LP.

There are many other venues -- which should be made clear in the wiki
-- that cater for casual user's issues (AskUbuntu, IRC, the Ubuntu Users
mailing list, and many, many others). IF an user, after passing thru
one (or more) of the user support offerings, ends up with a real bug...
then a LP/bugs entry is warranted.

BUT NOT BEFORE.
 
We do not want more people to open bugs. We want more people to open
*good* bugs reports. Reports that can be worked out by triagers,
maintainers, developers. This means the reports must be more on the
complete side. More on the technical side. Less on the "it did not
work". The triagers will complete the details. 

But I can guarantee you that a extremely vague bug will be left aside.
Which, BTW, I think is wrong: it should be closed INVALID (no actual
data provided).

> 
> And the second question is "would the proposed draft allow most
> people to report bugs?"

Yes, it will. And therein lies the danger. It is NOT easy to write an
usable bug report. Why should it be easy to write a bad one?

Cheers,

..C..


pgpMgdfb2wJMg.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Are you seeing this error in my emails?

[C de-Avillez]

On Mon, 1 May 2017 03:43:20 +0200
Alberto Salvia Novella  wrote:

> Chris Pollock just said me that he's seeing the following error
> message on the top of every email he's receiving from me on this list:
> 
>  >Error verifying signature: parse error
>  > --ms050806000101030505050803
>  > Content-Type: text/plain; charset=utf-8; format=flowed
>  > Content-Transfer-Encoding: quoted-printable
>  >
>  > https://goo.gl/forms/VDbXIhlFHVM6DleF3
>  >
>  >
>  > --ms050806000101030505050803--
>  >
>  > --  
> 
> Are you seeing that too?

No errors are shown here (running Claws-mail git had, version
3.15.0git30).

Interestingly, OTOH, I see no indicator stating your email is digitally
signed (but this is another issue).

Cheers,

..C..


pgpZTfeFuOZb6.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: I have written a draft for the Reporting Bugs guide

[C de-Avillez]

On Thu, 27 Apr 2017 04:41:19 +0200
Alberto Salvia Novella  wrote:

> Thomas Ward:
>  > While the purest form of the swastika comes from non-Nazi religious
>  > symbols, we should avoid using it because of the way it was twisted
>  > during the late 30s and 40s.  
> 
> The reason why the swastika is there is because that image is an 
> original blueprint from World War 2, and if you see the rest of 
> blueprints you will realise that the symbol was drawn by the original 
> author in a joky tone. The same as I had put the Microsoft logo there 
> (which curiously looks very likely).

The swastika has to go. 

*ANY* religious or political image, logo, or whatever should never be
used here.

The swastika, independent of where/when it was created, now symbolises a
dark time. Some -- myself included -- consider it abhorrent; in my
case, for personal family reasons.

> 
> (https://www.google.es/search?tbm=isch=blueprint+of+victory+wikimedia)
> 
> 
> Alvaro Leal:
> > Why did you make a video?  
> 
> Because it's my choice, and you respect that. The same as you respect
> my work, instead of going and destroying it.

> 
> Because the next email I'm going to read from you is going to have an 
> apology as title.

? Please calm down both Alvaro and Alberto. You may like videos for
personal reasons. Others may not. But this does not give any of you the
right to be offensive.

Cheers,

..C..


pgpphiD7bkxE8.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: I have written a draft for the Reporting Bugs guide

[C de-Avillez]

On Tue, 25 Apr 2017 09:43:21 +0200
Alberto Salvia Novella  wrote:

> Many people has been complaining through the years about not knowing
> how to report bugs in Ubuntu. I have been asking those people why is
> that, and they usually told me that the reporting bugs guide was too
> long, hard to skim, and nobody would be willing to read it.

> It wasn't till I putted a video-tutorial on the top of the page when 
> people stopped complaining about it. But that's just a dirty
> work-around and shows that the guide doesn't fit well the average
> user needs.
> 
> 
> So for:
> https://help.ubuntu.com/community/ReportingBugs
> 
> I have written an improved version:
> https://wiki.ubuntu.com/es20490446e/Reporting%20bugs
> 
> 
> The criteria I have used has been:
> - Adequate for the average person (https://goo.gl/GmzLhb)
> - Fits 95% of cases, and leaves the rare ones out.
> - Easy and straightforward, over correct.
> - Removing the already guided steps by applications themselves.
> - Removing the procedures only interesting for triagers.
> - If something is unclear if it's useful, adding it when it shows to
> be.
> 
> 
> Please have a look at it and tell me if you see something painful 
> missing. Thank you.

Quite simple indeed. 

One single thing at the moment (until I digest it all, including the
potential impacts): we should *not* announce how to directly enter a
bug in LP. Use ubuntu-bug. Otherwise, use ubuntu-bug.

You are making filing a bug available to the average user, whatever an
average user is. We know, already, that -- per your own words above --
these are the users that cannot read anything with many pages,
paragraphs, sentences, words. If you allow these users to directly open
bugs on LP (as opposed to using ubuntu-bug), then you taking out the
*only* way we can guarantee a *minimum* of hard data about the
system/progam/package affected.

Cheers,

..C..


pgp_DBVSk_qpF.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Perte de connexion wi-fi après mise en veille-réveil

[C de-Avillez]

On Sat, 4 Feb 2017 16:12:50 +0100
"freddy.gonth...@sfr.fr"  wrote:

> Bonjour,
> 
> J'utilise Ubuntu 16.04 LTS, kernel 4.4.0-62-generic, lorsque mon PC
> sort de veille ou d'hibernation, la connexion wi-fi est perdue et
> nécessite de redémarrer le PC pour redevenir active.
> 
> Est-ce normal ? Si non, existe-t-il une solution ?
> 
> Cordialement,
> 
> F. Gonthier
> 

(please copy the OP, he is not subscribed)

Translation:

I use Ubuntu 16.04 LTS, kernel 4.4.0-62-generic, when my PC comes from
suspend or hibernation, the wi-fi connection is lost and I need to
re-start the PC to recover it.

Is it normal [behaviour]? If not, is there a solution?

Cheers,


pgphV2VGUeZe4.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Administrivia -- emailing ubuntu-quality

[C de-Avillez]

Hello,

I would like, given the Teo Teo troll, to point out some things
regarding usage of the ubuntu-quality mailing list.

* aggressive behaviour is NOT acceptable. There are a lot of ways to
  express one's unhappiness with something. Being aggressive is NOT one
  of them. This mailing list (as the others in the Ubuntu echosphere)
  is governed by the Ubuntu Code of Conduct.

* ideally emails to the mailing list should be text only. Not all of us
  accept, or use, rich text (I am one of them that only read email in
  text).

* ideally responses should *quote*; you quote the piece of the email
  you are talking about, then you write your comments.

* there is, usually, no reason to attach video, or link to one (unless
  it is showing the issue being discussed. A response should be able to
  be read at the reader's pleasure.

Thank you,

..C..


pgpyB23DD2_Hm.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Upgrade was a disaster as usual <- still dead horse, just a clarification.

[C de-Avillez]

On Mon, 12 Dec 2016 03:45:31 -0500
JMZ  wrote:

> On 12/11/2016 07:12 PM, teo teo wrote:
> 
> 
> > 2) sticking to an LTS for 2 f***ing years means sticking to
> > tremendously obsolete software, usually full of bugs that have
> > already been fixed upstream (by the way that is usually already
> > true when the ubuntu release is brand new, let alone two years
> > later),  
> 
> 
> I know, someone's going to think, "don't feed the troll".  Hear me
> out. Teo teo's concerns about LTS are not trollish.  Users who elect
> to run LTS rather than incremental releases must, at some point,
> maintain the system with more current debs which approximate the
> incremental upgrades.  I always follow the incremental upgrades, as
> I'd rather fix a version which is farther along in development than
> LTS.  I never fully understood why a individual user would use LTS.
> LTS is better suited to a circumstance where uniformity is prized,
> such as small businesses, corporations, libraries etc.  Teo teo is
> certainly right that an LTS plan of action has significant deficits.

That might be true (that Teo's concerns may be important). Nevertheless,
s/he behaves in a trollish way, and *intentionally* has been evading
moderation.

S/he is moderated again.

I personally do not care if these concerns are valid or not -- I
stopped reading her/his comments the moment they went to Trollland.

There are many ways of raising an issue. The way s/he does it is not
acceptable on the Ubuntu ecosystem.

Cheers,

..C..


pgpo3LiiO9l3G.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Upgrade was a disaster as usual <- dead horse.

[C de-Avillez]

On Mon, 12 Dec 2016 05:56:15 +0100
Alberto Salvia Novella  wrote:

> Teo T.:
> > I guess my biggest mistake was to choose ubuntu in the first
> > place.  
> 
> I'm sorry you didn't like it.
> 
> 

OK. This thread is a dead horse.

And Teo Teo gets to be moderated. Again.

Let´s go back to improve Ubuntu. If anyone has ideas on what/how/why to
do something to improve Ubuntu's quality, by all means use this list.

Aggressiveness, on the other hand, is unacceptable.

Cheers,

..C..


pgpkkhHqT_Izt.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: #1543046 wrongly marked as fixed for Wily

[C de-Avillez]

On Fri, 8 Jul 2016 03:13:51 +0200
php fan  wrote:

> > And if it is not, then it would get marked "Won't Fix" when
> > someone goes through and does post-EOL-release cleanup.  
> 
> It sounds like that would be the right thing to do. If it's not going
> to be fixed, let's at least avoid people the frustration, confusion,
> and possible waste of time caused by having bullshit information on
> Launchpad.
> 
> Note also that, given that this bug was claimed to be fixed for Wily
> and it isn't, I am quite skeptic that it's really fixed in Trusty
> too. If I were a member of a QA team, I would test it on Trusty.
> There's a simple, copy-pastable command to run to see whether or not
> the bug is fixed. I would test it myself if I had any box with Trusty.
> 
> 
> 
> > and prepare your environments
> > for upgrading to Xenial when Wily dies on the 28th.  
> 
> Speaking of "preparing my environments" (that's funny btw: you
> shouldn't be supposed to have to "prepare" anything at all for an
> upgrade), so is there some "preparation" I can do to make sure that I
> don't brick my computer with the upgrade as per issue 1551623? Or at
> least, some check I can do to know whether my system is affected, so
> that I don't upgrade in that case? (I'd rather have a "dead" Wily,
> dead as in "past the EOL", than a dead system, dead as in "it doesn't
> boot").

@php4fan:

I expected you to have understood, as of now, that this list, and
all of the Ubuntu lists, are bound by the CoC.

As such, putting you on moderation.

Cheers,

..C.. 


pgpdF9Rxd4lPF.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Why wasn't I notified that I was put on moderation?? Now a Dead Horse.

[C de-Avillez]

On Mon, 27 Jun 2016 09:51:53 -0500
C de-Avillez <hgg...@ubuntu.com> wrote:



I allowed in the two previous emails, and my response, since they
were addressed to the ML.

Further emails about this from Teo will be dealt off the mailing list.

This thread is now a dead horse.

Cheers,

..C.. 


pgp5sOKyX8POq.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: The grep disaster

[C de-Avillez]

On Fri, 24 Jun 2016 21:57:47 +0200
php fan  wrote:

> Bugs like https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1535458
> shouldn't remain unfixed for more than a few days.

Hello Teo,

I think you already said that before, indeed more than once. You may
want to poke upstream about that.

Cheers,

..C..


pgpf6DcAatDCV.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Upgrading to 16.04 can render the system permanently broken

[C de-Avillez]

On Sat, 30 Apr 2016 02:06:03 +0200
teo teo  wrote:

> > In fact right now the Software Updater will only ask you to upgrade
> > if  
> you have enabled it to do so to any new Ubuntu release, but not if
> you have chosen to do only for long support ones.
> 
> Wait a moment, isn't Xenial an LTS release?

<...>

OK. This thread is now a dead horse. Please do not flog it anymore.
Points have been made, objections have been posted, etc, etc.

And Teo is still in the moderation queue.

Cheers,

..C..


pgpSoYrbhdeSF.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: There's an idiot mass-closing old unfixed bugs

[C de-Avillez]

On Mon, 18 Apr 2016 13:52:07 -0700
Brian Murray  wrote:



> I personally think that is disrespectful of the work the bug
reporter
> may have put into the bug report.  Additionally, lots of bugs do
> persist from release to release and plenty of packages use the same
> version across multiple releases.  Subsequently, I think bug triagers
> should make and effort to recreate the bug report and if there is
> insufficient information then proceed down the Incomplete path.

How about the following:

For bugs in EOL:
close all EOL-ed release tasks
if could_test (in a supported release):
update_bug with details & version tested
if cannot_reproduce:
update_bug "As such, closing blah blah"
close bug
elif no_time or no_knowHow or no_patience:
LEAVE_BUG_OPEN.

I think it is quite simple to follow the pseudo-code above.

In general, closing a bug because it is too old is the wrong move. It
is not triaging.

One may decide to only triage the current release or, maybe, only
the current in-devel -- it is one's decision. If you do not care about
older bugs, that's OK. But, still, old bugs are important.

Some people get nervous when they see the number of open bugs we have,
and think that by closing as many as possible we will "look better."

We will *not* look better. We will, on the other hand, look better if
we get more triagers, and do a decent triager work.

But, no matter what, the tone of the OP's emails is wrong.

Cheers,

..C..



pgpTjSRRPhtPV.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Do you think this bug really belongs to Linux?

[C de-Avillez]

On Mon, 18 Jan 2016 19:48:06 +0100
Alberto Salvia Novella  wrote:

> Brian Murray:
> > But what makes you concerned that it might not be?  
> 
> I thought that some of these could fall on the SystemD side:
> 
> Will Buckner at (http://tinyurl.com/gre4nwh):
>  > Instance Status Checks fail, and I can no longer SSH to the
>  > machine. Background daemons running on the system stop responding,
>  > and nothing is written to the logs.  
> 
> Although reading the logs it seems more probable to belong to Linux,
> as what triggers the bug is a general protection fault.
> 
> 

Alberto,

Please give your questions in full. "Is this right/wrong/good/bad"-type
of questions are not easily answered without context. 

For example, you could have posted your question as "I think linux is
the wrong source package on this bug, because {explanations of why YOU
think so}. Am I right?"

You tend to throw questions/opinions/comments without reference, or
context. Please do no do so.

Cheers,

..C..
-- 
ab alio expectes alteri quod feceris


pgpF3UQ8hMDD_.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Launchpad Greasemonkey Scripts

[C de-Avillez]

On Wed, 18 Nov 2015 15:26:36 -0800
Brian Murray  wrote:

> I've worked on and use some greasemonkey scripts[1] that modify
> Launchpad and make some tasks easier. One of them, lp_button_tags,
> isn't currently working and I thought this would make a good Google
> Code In project. Having said that it wouldn't be very rewarding if
> I'm the only person still using these.
> 
> So is anybody else still using these scripts?

Yes, I still use them. And I still like them (except, of course,
lp_button_tags, which has not been working for a while ;-)

Cheers,

..C..

-- 
ab alio expectes alteri quod feceris


pgpuYlCLx46Dv.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Asking users to upstream

[C de-Avillez]

On Wed, 29 Apr 2015 16:43:55 +0200
Alberto Salvia Novella es204904...@gmail.com wrote:

 Thomas Ward:
  (First character here is EMOJI - NonDisplay on Ubuntu +
  Thunderbird). We've had this discussion MANY times prior with you
  and on this list about using Emoji - don't.
 
 Okay, you are right.
 
 I promise I won't be posting emails with pictographs, at least while 
 Ubuntu LTS prints that horrible default character. And if the
 situation changed, I would be asking for your permission before
 posting them.

Please simply do not use them. You are assuming that, because you use
emojis, everybody else also does so.

This is not true (myself included). My emails are text-only, not HTML,
and no expectation of anything different. And we have to cater for
*all*, not only those that use, and can receive, emojis in emails.

There is a simple reason for that: text-only is the *common* base:
every email client supports it.

(Now, if I am texting, I will use emojis. No problems there.)

 On the other hand it's very sad not being able to use visuals, as I
 feel they bring plenty of dynamism when used adequately.

See above. It is, perhaps sad (personally, I do not understand why).
But it is certainly sadder when I receive an email with with them, and
lose the desired meaning.

 Perhaps string emoticons instead? (^_-)

Yes, please. Again, all email clients will display emoticons.

Cheers,

..C..

-- 
ab alio expectes alteri quod feceris


pgpXesKOh93Rf.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Is fixing bugs a responsibility of this team?

[C de-Avillez]

On Thu, 12 Feb 2015 00:35:40 +0100
Alberto Salvia Novella es204904...@gmail.com wrote:

snip/

 
 On the other hand there's no role in the Quality team intended for
 bug fixing, so the activity looks like it has gone orphan.

For a reason: QA is *NOT* development. BugSquad is *NOT* development.

 
 So these decisions need to be taken:
 - If to keep or to remove the Bug Squad.

It is kept.

 - Which are the ambit of responsibility of each team.

The *primary* activity of the QA team is QA. The *primary activity of
the BugSquad (and BugControl) team is bug *TRIAGING*. Neither QA not
BugSquad are involved in development (expect for their own tools), and
neither of them are involved in *FIXING* bugs (except for their own).

These are the TEAMS. A member of one (or both) of these teams may
perform other activities as well.

 - Where the bug fixing activity go.

Keeps as it is.

I think you are confusing things here. As Pali said, nothing prohibits,
or is made to inhibit, anyone trying to fix a bug. No matter what team
this person belongs to. In fact, many of us wear many, and sometimes
multiple, hats. For example, the fact that I am a developer, belonging
to a (code) development team in LP does not prohibit me from doing QA
(and lo and behold, finding a bug in a test and fixing it).

Cheers,

..C..


-- 
ab alio expectes alteri quod feceris


pgpvUWAgzFCDt.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: What if users warned about critical bugs?

[C de-Avillez]

On Thu, Nov 20, 2014 at 9:14 PM, Alberto Salvia Novella
es204904...@gmail.com wrote:
 C de-Avillez:

 I will try to stress the above a bit more: users in general will always
 assume their bug is high/critical (it is, by definition, affecting their
 work!).

 We did have it, sort of, on for a while -- and we found that importance
 would have to be controlled. We used to spend a nice amount of time
 correcting importance. Samewise with moving to triaged, or fix released,
 or wontfix.


 What do you see when you look at http://tinyurl.com/qefxjoo?

I am pretty sure I know the definitions for importance values but,
anyway, thank you for pointing them to me.

This, on the other hand, does not explain or justify giving end-users
access to setting importance (or even understanding how to set it).
Our experience on Ubuntu, and my personal experience when doing
support work professionally, still shows me that end-users should not
have access to importance, as implemented in LP. So, even if we are to
allow end-users (the original posters) to email BugControl stating a
bug is critical -- but *NOT* changing importance directly -- I have
serious doubts about how effective it will be.

This would be different if LP supported user-view of importance and
impact *separate* from bug importance as seen by the technical
resource -- developer or triager. But it does not.

Going on. We can try, perhaps by setting a new ML for that. But
definitely NOT by having the OP email BugControl. We can then verify
how much overhead it will be. At least for the beginning, I do not
expect many emails, but that might change as this new channel gets to
be known.

-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: What if users warned about critical bugs?

[C de-Avillez]

On 20/11/14 09:00, Brian Murray wrote:
 I think this is a false assumption, in that the people setting the bug's
 importance to critical know the definition of critical and are able to
 independently judge the bug's importance. Some Launchpad user reporting
 or experiencing the bug report is much more likely to think their bug
 report is critical. Subsequently, I think your numbers are quite low and
 optimistic.

I will try to stress the above a bit more: users in general will always
assume their bug is high/critical (it is, by definition, affecting their
work!).

We did have it, sort of, on for a while -- and we found that importance
would have to be controlled. We used to spend a nice amount of time
correcting importance. Samewise with moving to triaged, or fix released,
or wontfix.

 
 Another consideration is that the Ubuntu Bug Control mailing list is
 moderated so any emails sent to it will need to be approved by an
 administrator. I'd like it if a different system were used.

Agreed 100%.

Cheers,

..C..




signature.asc
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Please, review this Bugs Importances draft

[C de-Avillez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/10/14 21:10, Alberto Salvia Novella wrote:

 Thomas Ward:
 Why are you posting this on the QA list instead of the bugsquad
 list?
 
 Because I thought the Bug-Squad team had joined the Quality team a
 long time ago, and was listed in Launchpad just for historical
 reasons. So is this a mistake?

Well. Yes, and no.

YES, it is misrouted: BugSquad is responsible for keeping the triage
pages. By not addressing the BugSquad, you may be missing some
interested people.

NO, it is OK(ish): we discussed, some time ago, joining BugSquad and
Quality. At the time we thought of keeping the mailing lists and IRC
channels separate. I have been, lately, wondering if we should
consider a more radical approach.

[ given that I am subscribed to both the busquad and quality ML, I do
not have loss of information; but I cannot state how many are in one
and not in the other.]

Reasoning: I personally have always seen triage as one aspect of
quality. This view, to be completely honest, is NOT shared between me
and the luminaries of QA (and the discussion of why is too long) but I
do not mind: I still think that they are inter-related.

Right now, the Yes/No ratio (to Alberto's question) is at around 60/40.

Perhaps it is time to consider joining more of BugSquad to Quality.

..C..


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUOpYBAAoJECWAD5grd+mNqa0P/RRPhl1U5WOziAVAIG6uGAx1
6mQ00uHdtQTnBCbSR1hADHdVqR0g7xNxzi6F/yQbooQl7+V60gEv6CUFLz0GAtc3
21NmIXJdqEuirD3gCzvgkXSsBuYDMdZN2PjstaTJZRvolkp3Bk0IXTYl8Xu0ifvu
SvmLo7TWdgzBWEboQ4XNL/Rw9j5SzMrv6a0TA3LawZCKw2Kbe4I/WDgCS01SD4XJ
IgcSp02LlITmJ26pUQPfdoor5R9vG6Rds6pLbM32gsI8xrWeGM+vxlCjSUpAGTKz
vTB2MHK/yHi4ua++dcg2heLOwx2ekV1a7/yWVQExiOlau6W/Eheeg7jjo6DW9wRq
sRe+4xxS8x3eo8LW1wTyvVOAWq/FnZNJfWXJylVyV/dsddwn1rRCsDudBO5ajtj7
nsKaYFGTgyTrE+oWPNWYX2b1xwE6c9AoJAdVS3iYmsjeeg3sSOGEUyazVusUeNk8
ioRhDJOMa82mj6S+H9+c0k6OXpoUi88c+OkVoxMmRjrm29oKMzkN1CfDzd7AkzGB
l2J99z88Qapf2uXf9lw5M/Jo4isgJ6B6iF1ILD+gM1ewHlzrQapEZQ2SyintX+ir
r+d1Imd9k7nKjJ6DqLIL38h6nLNRn/8oJJTPOaV07fNqOwUTXDd+o6vKLThffzaF
CDp6+QUu8/VKqdfXjK65
=ahRj
-END PGP SIGNATURE-

-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Who can see private bugs?

[C de-Avillez]

On Thu, 21 Aug 2014 05:15:04 +0200
Alberto Salvia Novella es204904...@gmail.com wrote:

 Who can see private bugs?

Depends on a series of factors. Usually the ones we -- *Ubuntu*
triagers -- are interested in will be accessible by members of the Bug
Control team.

Private bugs under different projects (in other words, *not* opened
against an Ubuntu package) will be accessible only to members of the
affected projects.

Security bugs that are opened private are only accessible by the
Security team.

In general, private bugs opened against an upstream project are only
accessible to project members.

 Are private bugs automatically marked as confirmed under any
 circumstance?

Yes, they can.

..C..


-- 
ab alio expectes alteri quod feceris


pgp_Yk2SGwtCn.pgp
Description: OpenPGP digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Common situations where a bug isn't real

[C de-Avillez]

On Mon, Jun 16, 2014 at 2:57 PM, Alberto Salvia Novella
es204904...@gmail.com wrote:
 I've been writing a list of common situations where a bug isn't real:

 https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Work-flow/Triage/Real

 Do you know of some other?

Just a few comments:

Be careful with #1 (it is not open source) -- it may have been
packaged by Debian (or Ubuntu), and it may be a packaging issue.

Being an idea for a new feature can be closed and the OP redirected to
upstream to propose it. In the cases where Ubuntu is the upstream, the
bug can be kept open, and an upstream task opened.

The last one is just a particular case of system misconfiguration.

Cheers,

-- 
..hggdh..

-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: This needs attention

[C de-Avillez]

(I am using Gabor's email to answer a series of points in many emails.
I am just using his email because it is much clearer, complete, and
nice than some of the previous emails.)

On Tue, May 27, 2014 at 1:35 AM, Gabor Toth gabor...@gmail.com wrote:
 Hi,

 I feel like I need to say something to this conversation as I found this
 subject quite disturbing.  As part of my work I install Ubuntu systems to
 customers and use Ubuntu for long years now, having been through almost all
 distros of Ubuntu.  I have done some testing too and helped on bug squad
 some.  These days did not have that much time to contribute, but I do my
 best as you guys.

I also find the OP's comments quite disturbing.

I am also curious: have you had this issue yourself? I hear around
that this is a critical bug, that the skies will fall if it is not
fixed, that everybody is affected by it, etc. But I personally do not
know anyone that has been affected, and I have not had this issue
myself, on all of my 26 upgrades to Trusty. And yes, I do have some
systems with more than one drive; but none with other OSes installed.


 While the discussion on this forum seems to be a lot of back and forth this
 is nothing to what is going on on the actual bug report and forum there.
  Reading it through I do not have a doubt in my mind that this IS an actual
 bug even though I am not effected by it.

I beg to differ. If -- and this is based *only* on the original issue
in the bug -- the user had two different installs of Grub on two
different disk drives, and (for whatever reason, however it may have
happened) the Grub configuration got mixed/lost/confused, *then* this
(original) error will pop up.

 If one does a dist upgrade and
 his system was working before and after the upgrade going through without
 any warning it lives him with an unusable (even though fixable) system it
 is something you would not expect dist upgrade to do - thus it is a bug,
 per definition of a bug.

No. Code changes. If (and, again, discussing the *original* issue in
the bug) you had multiple installs of one thing, and the system does
*not* know bout these multiple installs, then it is not a bug. If is
an user error. In this case, it was caused by a stale copy of Grub
being run. If what I just said does not apply, then it is a
*different* bug.

A part of a system does something that you do not
 expect it to do and of course it is quite high priority since en entire
 system becomes broken and it apparently effects multiple users.

 There is something else quite disturbing though.  There seem to be one
 person in the programmer side of the team that keeps disagreeing with the
 everyone else and is able to push her own opinion (which seems very wrong
 by the way) in front of the entire community.

Perhaps because he knows what he was asking for and doing, as opposed
from almost every other commenter in the bug. Please keep in mind that
a bug is a *technical* report about an error/failure. It will be
looked at by *technical* people. As such, It HAS to have technical
data.

  When you look at the bug
 report the status is being set back and forth and that one person
 apparently just cancelling this bug while it is reported by a number of
 others.

And stating why. And being disregarded. I personally would have put
the bug as OPINION a long time ago. The *only* thing that may still be
done is explain, in the bug description, WHY, and WHAT can be done.

Let me try to clear some (possible) misconceptions about bugs, and how
we deal with them (both for triaging, and for fixing).

The first two are *dogmas*. We will not change them.

* one issue per (bug) report
* one (bug) report per issue

This means a Launchpad bug should describe one, and only one, issue.
If multiple issues are shown in one single bug report, then they HAVE
to be broken down to different Launchpad bugs. This is not required
because we are mean (developers|triagers), but because we need to be
able to backtrack a fix to a bug (and vice-versa). If the fix
introduces a (new) failure, then we need to be able to pinpoint it to
the correct bug report. This would not happen if we have multiple
issues per bug.

In this specific bug, we have at least two different issues being
conflated; we also have the original reporter's issue being shown as a
failure (user's, or perhaps grub's); a way to fix it was provided
early on (and it should be clear that the issue came about mostly
because, at some point in time, the user used the wrong command
sequence to update Grub).

As such, the original report *has* to be closed.

Many times throughout the hundreds of comments Phillip stated that. I
will also note that I personally will tend to trust Phillip: he
usually knows what he is talking about and, certainly, he knows more
than I do on Grub.

* When you open a bug, please add the (minimum) required data.
Ideally, *NEVER* open a bug by hand (almost all of the opened-by-hand
bugs miss the minimum required data).

Phillip, while 

Re: This needs attention

[C de-Avillez]

On Tue, May 27, 2014 at 2:05 PM, Alberto Salvia Novella
es204904...@gmail.com wrote:
 On 27/05/14 16:56, C de-Avillez wrote:

 A technical opinion on a technical issue will rule out every other
 opinion until proved wrong.


 Summarizing: for confirming this bug, you need to provide a series of steps
 that will break GRUB consistently.

 Till then the appropriate status for the report is opinion.


Actually, even then I would rather have a new bug opened. This one is
done and gone :-)

-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Help with bug confirmation

[C de-Avillez]

On Wed, 16 Apr 2014 15:32:33 +0100
Colin Law clan...@gmail.com wrote:

 On 16 April 2014 14:44, Pierre Equoy pierre.eq...@gmail.com wrote:
  Hi Colin,
 
  I don't have a multi-screen configuration at home, but I do at work.
  Do you think I can try it using simply a Live CD or a VM? Or does
  it require to install the system completely first?
 
 I will try it with a live image, I would expect it to fail similarly
 but I have not confirmed that.  I will get back when I have tried it
 (I have not got one at the moment so it will be some hours).


I can reproduce it, and will update the bug in a few. My setup is
slightly different: instead of side-by-side, I have a monitor over the
other.

When I set the launcher to only appear on the built-in display (it is a
laptop), then I can repeat it.


-- 
ab alio expectes alteri quod feceris


signature.asc
Description: PGP signature
-- 
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

[C de-Avillez]

On Wed, Apr 9, 2014 at 2:52 AM, Alberto Salvia Novella 
es204904...@gmail.com wrote:

 El 08/04/14 22:35, C de-Avillez escribió:

  Sorry, I do not understand what you said above. Can you please rephrase?


 Yes: Although bug management does not apply to workflow bugs, they still
 have to be worked first by developers. So setting these as critical is a
 visual aid for them.


Why? This is not a bug, it is a workflow. If this is not a workflow you are
*involved* with (as, for example, 100 papercuts) you *cannot* change
anything in the workflow bug without clearing it out with the people that
actually work them.

It does not matter if my personal perception is this is a critical
(workflow) bug for *me*: it is NOT a workflow under your responsibility.




 El 09/04/14 00:52, Thomas Ward escribió:

  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.

 Because this is prone to mistake, perhaps we can warn in the Bug Statuses
 page itself that these bugs are not covered in that policy.


Agreed.



 El 09/04/14 00:52, Thomas Ward escribió:

  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.).

 There's another relevant part of setting importances for all bugs


You again are mixing real bugs and workflow bugs.


 , which is bugs that really need its importance to be set can be
 catalogued in work-flows made of list; without having items in these that
 cannot be cleaned up.

 For example, in the following work-flows:
  - https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Work-flow
  - https://wiki.ubuntu.com/UbuntuBugControl/Final%20clean-up
  - https://wiki.ubuntu.com/Bugs/Ubuntu%20Bug%20Weekend

 Summarizing: While changing status for this bugs can disrupt development
 work-flow, setting their importance to a default value can be a visual aid
 for everyone.


Sorry, this does not make sense for me: I will rephrase, as I understood
the above sentence:

while changing status for workflow bugs can disrupt development workflow,
I do not care. It is not my workflow.

The importance will be set by the people working this workflow, if they so
want to. Otherwise it should be left as is.

-- 
..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

[C de-Avillez]

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

Some points on the Wiki for Bug(squad|control)

[C de-Avillez]

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
tinyurl.com/pm76zuw, 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 tinyurl.com/pm76zuw, 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


signature.asc
Description: PGP signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Ask users to only assign just before starting working

[C de-Avillez]

On Thu, 16 Jan 2014 21:09:18 +0100
Alberto Salvia Novella es204904...@gmail.com wrote:

 I think, in the wiki, we should *ask users* to assign bugs only when
 the assignee will be able to work on it in a very short term.
 Otherwise those bugs can stay *unattended* for years.

More correctly, one should assign oneself *ONLY* if:
 * working on a fix
 * doing it NOW (not tomorrow/next week/month/year)

A bug assigned to somebody is a clear sign to others that it is being
worked on, and we need not worry about it anymore.

Cheers,

..C..

-- 
ab alio expectes alteri quod feceris


signature.asc
Description: PGP signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality