On 29/05/18 04:46 AM, Simon Lees wrote:
Just what constitutes "filing a bug" on a mailing list? There are many posts on opensuse-factory@, that are along the lines of I updated to the latest snapshot and XYZ broke, these are what we'd prefer to have as bugreports.
Oh, yes, I can see that. The key being "... I updated to the latest snapshot..." But there are many that are clearly misunderstandings or lack of understanding that are not bugs. I recall I tried converting one file system to XFS to try things out with that FS and everything was fine until I rebooted. I had the sense not to do this with a major FS, is I could keep my system running despite the problems. There's nothing wrong with XFS, it was wrong with me. Not a bug. Filing a bug would have resulted in a NOTABUG or a WONTFIX and left me floundering. This wasn't a bug and it wasn't a support issue, it was an issue that was fixed by the 'wisdom of crowds', which is the way the forum works. There was no 'latest snapshot'. There was no bug. There is a LOT of lack of deep understanding about specific subsystems on the part of many parties. perhaps it is documented, but it isn't always easy to find. It's all very well to say 'Go Google", and many of us do but find not solution. In many ways the Mint, Arc and Ubuntu have more stuff online, but so much of it is long winded, petty discussions in formats that have so much 'whitespace' and 'overhead', that it is hard to get to the relevant stuff. it's not that openSUSE documentation is any better, certainly not compared to RedHat, but what *is* important is that somewhere in the 'wisdom in crowds' is that someone can give a reference. Perhaps a reference to the matter already having been covered in the list, but lets face it, the search tools for the lists are abysmal. Yes, you are 100% correct about the "... I updated to the latest snapshot..." items needing to be bug reports. In that case we ARE dealing with new code, changes to code and configuration. But a lot of what comes up at the main forum is not about new code. It is about people doing things differently, using programs which do not do as they expect even though the program is quite OK. It is about expectations. These are not bugs. In many ways they don't even constitute support issues in the sense that pay-for-support is meant. There are a lot of programs that are quite complex and have many, many facilities whose details are complex. Perhaps they are documented, in a manual six inches thick if it were to be printed (I'll skip the 'Beware of the Leopard' sign on the lavatory door part). So you come to use a new module and hit a "DUH?" and the best way to have it solved is by a mentor. It is abut 'individual wisdom and experience' that is absent from the formal 'support' process, the formal bug processing system. Back in the AIX days I mentioned the reality was that I knew more about UNIX-per-UNIX and the upper layers of the kernel than the people doing support, and in some cases the developers down in Austin, Texas. At one point I was telling them what the code on their screens was and they were treating to sue me for infringement. I hadn't told them that I'd worked on the that code as a UNIX developer myself. Apparently I reduced one of them to tears. But while my knowledge was systematic it was also getting out of date. *I* couldn't do that today, but I'm sure that there are users on this list who do have specific knowledge and experience on USING the software that even surpasses that of the developers. That's what I mean by 'wisdom in crowds'. Then there's https://en.wikipedia.org/wiki/Crowdsolving which is quite another matter. But don't ignore it. You don't get that with the formal ideas of 'support'. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org