(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 <[email protected]> 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.. -- Ubuntu-quality mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
