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.me at 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 pointing (again and again) that the original issue was
done with, also asked for new bugs to be opened.

* refrain from "me too", "this sucks", "you are all idiots" comments.
They do not help, they pollute the bug with useless comments, and they
pretty much guarantee that any willing developer will give up with
disgust.

We do a lot of things. I frankly am not interested in a pissing
contest -- I can spend my time more productively elsewhere.
Additionally, there is a button on the bug that you can use to state
"me too". Use it. Help free bytes in storage.

* use ubuntu-bug to open a bug. Do *NOT* open it by hand. Reasons
already provided but, in addition, ubuntu-bug can collect most of the
data we need to look at them bugs (if it misses a critical piece of
data, then we can change the hook to add it in).

>
> This very point is the main concern on this whole thing.  If Ubuntu is a
> community, which it should be, then this should not ever happen.  One
> person's opinion should not over rule everyone else's opinion.

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

> I am not
> sure who she is, but this whole process was not something that you could
> call an executive decision.  Perhaps she had no capacity, knowledge, or
> interest to fix this bug and thus wanted to put it under the carpet for
> whatever reason.  And the reason does not even matter here!  It is a
> community and this would be a point when others could step in an offer
> their expertise and time and do fix the bug.  However with her actions she
> did not only stepped down, but also stopped others to work on it since she
> simple "cancelled" this bug out entirely.  And this is not some little
> design point or some minor program we are talking about but either grub or
> the dist upgrade process that has a functionality which should not be that
> way to be able called "workable".
>
> Per what I see something is working if it requires no attention in the
> future and it just does what it should.  This is per definition "working".
>  Anything else is a bug.

No, anything else is a *probable* bug, until proved to be, or not, one.

>
> Now, if I install an Ubuntu system, say on a customers computer, and make
> that system a workable system (which sometimes might require some custom
> tuning due to no out of box support for some sort of hardware) then I would
> think that this is a workable system and the user, with no knowledge of
> command prompt, not knowing what grub was and if thinking that dpkg was
> some special ice cream should not be able to break a fully workable system
> just by clicking on a button of dist upgrade and entering her own password.
> And again, in some of the mentioned cases there was not even any manual
> config and handling of the system but was a clear automated install broken
> by a simple upgrade.

I agree. Please show, and document, such a case in a NEW bug. We do
not mind if hundreds of new bugs get opened, we can join them if we
are sure they are duplicates. But we will not work on multiple,
confused, issues in a single bug report.

Keep in mind that not everything that walks like a duck and quacks
like a duck is a duck.

> I personally think that we as a community need to look at this issue and I
> am not talking about the bug itself (which needs to be fixed too) but the
> issue of one person's opinion could cancel out (and thus enrage) other
> people of the community with living an issue hanging in the air with no
> apparent way of solving the different opinions in any way shape or form.
>  It should not be that who has a higher authority that is right no matter
> how wrong she is.

...

He is not wrong. At least, he has not been proved wrong so far. The
original issue was shown to have been caused by having two copies of
Grub installed, and the system only knowing about one. It happened
*not* to be an issue because the code was at the same version. We can
discuss how that (two different copies of Grub) happened; perhaps
there is a bug in here. But it has to be done in a new bug, and
documented with technical data (logs, whatever).

>
> Is there anyone at canonical that can take a look at this?  Seems a
> correction of this particular programmer needed on dealing with community
> raised bugs specially because she won't be able to work like this with the
> rest of the guys if she does not let them propose solutions and fixes but
> trying to silence them.

Just to clear a point here. Canonical has NOTHING to do with it. This
is Ubuntu. This is a community. The Ubuntu community can do something
about it. It just happens that Canonical *pays* the salary of many
Ubuntu developers. But this does not make Canonical the manager of the
Ubuntu community. So, to answer the question: no, there is nobody at
Canonical that can help.

>
> With Kind Regards,
>
> Gabor Toth

I see you are frustrated. I am sorry for that. But we cannot confuse
the issue even more. I do appreciate your email, and the care you took
in writing it. But I think some of the points you raise are not
entirely correct. This is why I am using your email to try to dispel
some of the misconceptions I seen in this thread and in the bug in
question (I will not bite on trollbait).

I will be more than happy to keep discussing this with you, until we
reach a consensus.

Cheers,

-- 
..hggdh..