SR's & Bugs

Non-Technical Threads Talk to a SUSE Technical Services Manager
1

So, I just need to understand what the policy is supposed to be…

I’ve had bug’s raised as a result of a SR, then the SR gets closed and
the bug is “employees only”…so I’ve lost complete view of when the
bug will be fixed with the SR providing no workaround.

This seems to be completely counter intuitive.

–
-“Also now available in ‘G+’
(http://plus.google.com/+BenWalter-Kiwi) and ‘Website’
(https://www.isam.kiwi/) format”.- :wink:

ScorpionSting’s Profile: https://forums.novell.com/member.php?userid=1663
View this thread: https://forums.novell.com/showthread.php?t=505154

2

Hmmm…got call as result of Survey against one of these…both have
been reopened now

–
-“Also now available in ‘G+’
(http://plus.google.com/+BenWalter-Kiwi) and ‘Website’
(https://www.isam.kiwi/) format”.- :wink:

ScorpionSting’s Profile: https://forums.novell.com/member.php?userid=1663
View this thread: https://forums.novell.com/showthread.php?t=505154

3

Hello,

Thank you for asking the question.
Normally when a defect needs longer to resolve, more than 1 month, the
engineer may chose to temporarily close the SR.
Temporarily means both customer and engineer would still get automated
email notifications every time the defect is updated.

Once the fix is officially available, the engineer would re-activate the
SR, and follow up with the customer to make sure it does what it is
supposed to do.
If the fix does not meet the needed requirements, Engineering needs to
follow up the defect.

Even if the SR is closed, activities would still happen.
Instead of the SR being used as a place holder, the defect is used
instead.
Even though there is no visibility, the SR is still listed as Closed,
Awaiting Engineering, or Awaiting Public Patch, in NCC.
It becomes the engineer’s responsibility to close the loop.

I hope the above answers your question.

Regards
Tarik

–
tbaki

tbaki’s Profile: https://forums.novell.com/member.php?userid=13755
View this thread: https://forums.novell.com/showthread.php?t=505154

4

Theory sounds okay, but I think reality is very different. As a
customer, I need a direct contact point to check in when the resolution
to the defect is going to be released and this is not possible if the SR
is closed off and the bug is inaccessible.

Even when I have had bugs tied to an SR, the only piece of information I
ever received is the notification of the release several days after the
patch is actually out (likely when the bug is marked resolved). This
alone is insufficient.

–
-“Also now available in ‘G+’
(http://plus.google.com/+BenWalter-Kiwi) and ‘Website’
(https://www.isam.kiwi/) format”.- :wink:

ScorpionSting’s Profile: https://forums.novell.com/member.php?userid=1663
View this thread: https://forums.novell.com/showthread.php?t=505154

5

Thank you for highlighting ways to improve our customer interactions for
defect related issues.
If the theory does not work as expected, we need to review it.

Defect updates should not really be once , and only after final release
of a fix.
It should be with every status change of the defect, which is meant for
external communication.

If I understand you correctly, you are using the SR as a sounding board
to ask for regular defect updates.
This is still a manual process needing the engineer to regularly update
customers, and this could also fail.

If you are interested in a time frame for a defect fix, then I would
recommend that defects needs to be properly prioritized, in order for
developers to fix it in an acceptable time frame.
For this, both business and operational impact are captured and
communicated back to Engineering.

If on the other hand, a defect is not considered as high priority by
customers, then it will likely take more than a month to fix.
This is when automated defect updates are generally accepted by
customers.

An SR remaining open for over 3, 6, and 12 months due to defects, hardly
adds values, and does not reflect good practice…

If you were automatically updated via defect, every-time it changes
status, would that be acceptable?

I must reiterate that the SR is only “temporarily” closed until a fix is
released, or until such a time customers ask for it to be reactivated.

–
tbaki

tbaki’s Profile: https://forums.novell.com/member.php?userid=13755
View this thread: https://forums.novell.com/showthread.php?t=505154

6

When a bug is marked for “Micro Focus Employees Only”, no external
communication would occur. And as this is 100% the case when a bug is
logged via a SR, then no bug update affects the SR. Then with bugs I log
(making them external) and tie them to a SR, almost 100% of the
engineering updates are private so, again, the process falls apart.

I have at least 2 SR’s and their relative bugs that are completely
stopping us from moving any version of IDM 4.6.x beyond the DEV
environment. These are critical as IDM 4.5.x current ends support
February 2018 (which we can’t meet as it is with December and January
always unavailable for changes to our environments). I know one of the
bugs is tied to bigger issues around the ECMA implementation in the 4.6
release, so is high priority with engineering.

I have SR’s that are almost 2 years old, simply because of the lack of
any traction by engineering. Without the SR remaining open, I wouldn’t
have front line available to always be chasing engineering for a
response…and now making them 100% under the Product Manager radar.

All in all, the whole engineering process needs a complete overhaul if
any SR/Bug process is going to work correctly…until that happens,
making promises about “system notification functionality” would be
pointless.

–
-“Also now available in ‘G+’
(http://plus.google.com/+BenWalter-Kiwi) and ‘Website’
(https://www.isam.kiwi/) format”.- :wink:

ScorpionSting’s Profile: https://forums.novell.com/member.php?userid=1663
View this thread: https://forums.novell.com/showthread.php?t=505154

7

If you say the defects are high priority then the SR’s should not be
closed in the first place. This way the engineer provides regular
updates until closure.

Each product portfolio has its own bugzilla guidelines. Maybe it is the
case for IDM that every defect logged is marked employee only, but this
is not the case for other products. I will investigate and let you know.
Just to clarify that we are not talking about engineering updates being
visible and shareable via email.
I am referring to the defect status change.

I was not making promises, I was seeking your feedback. Anyway, it has
come across loud and clear.

–
tbaki

tbaki’s Profile: https://forums.novell.com/member.php?userid=13755
View this thread: https://forums.novell.com/showthread.php?t=505154

8

ScorpionSting wrote:
[color=blue]

All in all, the whole engineering process needs a complete overhaul if
any SR/Bug process is going to work correctly[/color]

I concur completely!

I have raised similar issues in the past as have other Knowledge
Partners. We would be happy to provide our input if it would help
resolve these issues.

It’s unfortunate that different products have different rules and
processes. When dealing with vendors, Customers expect issues to be
resolved in a consistent manner independent of the specific product!

–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below this post.
Thank you.