On 29/05/18 04:46 AM, Simon Lees wrote:
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
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
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
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
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
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
That's what I mean by 'wisdom in crowds'.
which is quite another matter. But don't ignore it.
You don't get that with the formal ideas of 'support'.
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(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org