Red Hat Bugzilla – Bug 57018
Differentiation between Open source and contract bugs
Last modified: 2007-04-18 12:38:32 EDT
Description of Problem:
When submitting bugs there needs to be a simple way to differentiate
between a bug submitted to be fixed under contractual support and an
OpenSource bug which im reporting FYI but has not yet caused my a problem.
Is this not solved by making a bug viewable to the "eCos ASCOM PLC Contract"
group only equivalent to making it a contract bug, and leaving the bux unchecked
equivalent to making the bug public?
Some contractual bugs im happy to leave visiable to the public, eg the libc
fflush bug i reported today on behalf of Robin.
There is a special permission group called 'setcontract' that makes a check box
show up on the bug entry form if you are a member. It basically is a check box
allowing for the bug to be marked as a contract bug which causes a warning box
to be displayed on the screen when a person logs in that has outstanding
contract bugs assigned to them. People who need to be able to make contract bugs
need to be added to that permission group.
OK, I see the new field now. Is the intention that we also give the permission
to set this field to customers who are using Bugzilla, or is this an internal
Normally what happens is that a new group is created that pertains to a
company/contract such as 'Intel Confidential' etc. The one or two people from
that group are given the ability to enter bugs as contract bugs and are placed
into the 'setcontract' group. That group gives the ability to make a new bug a
contract bug by clicking the checkbox when submitting and also make a current
bug report a contract bug by changing the priority to contract when making changes.
So it is not necessarily an internal only field.
OK, gotcha! I set Andrew to a member of that group so he should now be able to
change the priority of the bugs he submitted.
The only problem I can see is that the customer can set the priority of *any*
bug as contract, not only their own.
We really need a facility to that allows submitters who are paying customers
(i.e. support contracts) and members of "setcontract" only to set the priority
of a bug to contract, and even then this should only be allowed by the submitter
if they have support on that component.
Actually they worst thing that could happen is that someone with setcontract
privileges could set a *public* bug as a contract but I do not see that
happening. Otherwise the can see bugs marked private to their own contract group
not others. So if say a bug is marked private to 'Intel Confidential' and
someone who is only in 'Compaq Confidential', they would not be able to see it
much less edit the priority. Unless they were actually members of both groups
which would normally be RH employees. Of course I may be missing your point
No. You got the point, which is someone with setcontract priority could set an
arbitrary public bug with "contract" priority.
I am just concerned that this may put whoever is assigned that bug into a
tailspin . This is open to abuse by customers given this priviledge (not that we
don't trust them, just that not all are as trustworthy as you Andrew ;-).
Maybe a better solution would be to allow the "contract" priority to be set by
someone if they are in a "contract" group (like "Intel confidential"), and only
for bugs submitted by members of the same contract group. Then "setcontract"
could be for internal use only.
Red Hat's current Bugzilla version is 2.18. I am moving all older open bugs to
this version. Any bugs against the older versions will need to be verified that
they are still bugs. This will help me also to sort them better.
I think this bug can be closed.
Alex Schuilenburg is no longer interested since he no longer works for RedHat
after they closed down the U.K. eCos group. The support contract that Ascom had,
and that i was the technical contact person for, is long since over.
The issue of "Differentiation between Open source and contract bugs" is now a
mute point since RedHat is no longer active in the eCos field, except for Mark
Salter does RedBoot ports every so often.
The only reason to keep this bug would be if the same problem applys to other
pieces of software Redhat has customer support contracts for, and this problem
is not solved by v2.18 of Bugzilla.
Tighter integration now between Bugzilla and Issue Tracker (RH's internal CRM)
can now be used to tell which bugs are from customers are ones that are not.