Bugfixing procedure

[monte]

Are all bugfixes meant to go via bugzilla... even very minor ones? For example, I've found that mobileControls returns deleted controls because they must be referenced elsewhere... It looks like the m_deleted property was added for this reason but not checked in MCNativeControl::List... it's a fairly trivial bug fix so going to the trouble of posting to bugzilla with a stack and asking to be assigned seems like red tape... obviously for something more significant might warrant the extra work...

[LCMark]

I have a dislike of red tape as much as anyone - but in this instance I don't think it is that.

Whilst the underlying changes to the engine to fix a bug maybe 'trivial', there is a still a need to track the bugfix in terms of what release it goes into, be able to make sure it has been fixed and documenting the fix. Having a unique bug number to refer to individual bugs makes this much easier.

I don't mind the process being short-circuited slightly - i.e. post the bug, ideally a stack that demonstrates the problem and the resulting fix, and a reference to the pull request all in one go.

Moving forward, I can't see us dropping the requirement for having a unique bug number, but documenting and test cases will be easier because these will sit in the engine repository so you can submit the fix, the test case and note about the fix all within one pull-request.

[mwieder]

My take on this as a QA engineer: if the bug fix takes care of a problem in a released build then it should be entered in bugzilla. If you're fixing a bug in the develop branch or some other branch that is being worked on but hasn't been released to the public, then a pull request should be all that's necessary, as the git history will track things correctly. But otherwise bugzilla allows for following the bug history in terms of what was reported, the version it was reported against, the version it was fixed in, etc, so that the proper forensics can be done as needed.