Date: Wed, 09 Dec 2020 12:03:34 +0100 From: "Kristof Provost" <kp@FreeBSD.org> To: Peter <pmc@citylink.dinoex.sub.org> Cc: "Kyle Evans" <kevans@freebsd.org>, "FreeBSD-STABLE Mailing List" <freebsd-stable@freebsd.org> Subject: Re: Panic: 12.2 fails to use VIMAGE jails Message-ID: <5AC3DABA-E556-469C-926B-13484E75E64B@FreeBSD.org> In-Reply-To: <X9Cs5Pt6F16dDm3l@gate.oper.dinoex.org> References: <20201207125451.GA11406@gate.oper.dinoex.org> <39DBEA53-960F-4D70-86D7-847E6DFA437D@FreeBSD.org> <20201207233449.GA11025@gate.oper.dinoex.org> <DDDE7802-1C8C-4EB7-AA0C-DFCD7E5D2BAB@FreeBSD.org> <X8/Kr0td1cxI%2BP%2BV@gate.oper.dinoex.org> <1AAE98C9-ADF9-4869-B863-601542CEBB67@FreeBSD.org> <X9Ao%2BBKDXADds36A@gate.oper.dinoex.org> <CACNAnaGfwKG4UKsUWmYObeAexk3LZjLrKwevXvJnyS0pbGZReQ@mail.gmail.com> <X9Cs5Pt6F16dDm3l@gate.oper.dinoex.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter, I’m not interested in discussing software development methodology here. Please drop me from this thread. Let me know if/when you have a test case I can work from. Regards, Kristof On 9 Dec 2020, at 11:54, Peter wrote: > On Tue, Dec 08, 2020 at 07:51:07PM -0600, Kyle Evans wrote: > > ! You seem to have misinterpreted this; he doesn't want to narrow it > ! down to one bug, he wants simple steps that he can follow to > reproduce > > Maybe I did misinterpret, but then I don't really understand it. > I would suppose, when testing a proposed fix, the fact that it > does break under the exact same conditions as before, is all the > information needed at that point. Put in simple words: that it does > not work. > > ! any failure, preferably steps that can actually be followed by just > ! about anyone and don't require immense amounts of setup time or > ! additional hardware. > > Engineering does not normally work that way. > > I'll try to explain: when a bug is first encountered, it is necessary > to isolate it insofar that somebody who is knowledgeable of the code, > can actually reproduce it, in order to have a look at it and analyze > what causes the mis-happening. > > If then a remedy is devised, and that does not work as expected, then > the flaw is in the analysis, and we just start over from there. > > In fact, I would have expected somebody who is trying to fix such > kind of bug, to already have testing tools available and tell me > exactly which kind of data I might retrieve from the dumps. > > The open question now is: am I the only one seeing these failures? > Might they be attributed to a faulty configuration or maybe hardware > issues or whatever? > We cannot know this, we can only watch out what happens at other > sites. And that is why I sent out all these backtraces - because they > appear weird and might be difficult to associate with this issue. > > I don't think there is much more we can do at this point, unless we > were willing to actually look into the details. > > > Am I discouraging? Indeed, I think, engineering is discouraging by > it's very nature, and that's the fun of it: to overcome odds and > finally maybe make things better. And when we start to forget about > that, bad things begin to happen (anybody remember Apollo 13?). > > But talking about disencouragement: I usually try to track down > defects I encounter, and, if possible, do a viable root-cause > analysis. I tended to be very willing to share the outcomes and. if > a solution arises, by all means make that get back into the code base; > but I found that even ready made patches for easy matters would > linger forever in the sendbug system without anybody caring, or, in > more complex cases where I would need some feedback from the original > writer, if only to clarify the purpose of some defaults or verify > than an approach is viable, that communication is very difficult to > establish. And that is what I would call disencouraging, and I for > my part have accepted to just leave the developers in their ivory > tower and tend to my own business. > > > cheerio, > PMc
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5AC3DABA-E556-469C-926B-13484E75E64B>