Talk:Contributing Patches

Handling patches in IssueZilla (Draft)

patches do have the Issue Type PATCH when get subbmitted in the Issue database.

In case a patch implements a FEATURE or ENHANCEMENT this issue type stays at type PATCH until:

• The patch has been committed to a child workspace (cws)

• and has been marked as fixed

• and has been verified by the QA person for that cws.

At the time the cws get QA approval, the issue needs to get the type FEATURE or ENHANCEMENT if such is implemented. Also it needs to get check if specification, Feature mail also have been completed.

Stats invalidated

Please note that a change of the issue type from PATCH to something else will invalidate our patch handling metrics. I strongly recommend not to change the handling before the statistics gathering accomodates the new workflow.

Comments

 I think it's better that the issue type is changed when the CWS is approved, not when the PATCH
 issue is verified.

 Changing it's type to ENHANCEMENT or FEATURE before the complete CWS is finished might lead to
 undesired results if the CWS goes back to engineering. The patch might or might not be the reason
 for CWS-QA failing, but terms and semantics (and statistics) become fuzzy if in such a case the
 issue is an ENHANCEMENT/FEATURE, but still needs patch-polishing.
 (FS)

Benefit from the change of type

I do not (yet) understand the benefit of the effort to change the type. Could someone explain where we have a significant advantage. OTH I see the additional burden and risk to forget the "correct" handling. This might lead to new stumbling blocks instead of removing these. Please let's make contributing patches and timely handling of patches easier. Patches are 3% of all issues (2100 of 65000); open patches are 1% of all open issues. Let's discuss this again when we are at a ratio of more than 10%. --stx12 10:53, 5 October 2006 (CEST)

An earlier blog entry has some thoughts on the topic. --stx12 11:37, 5 October 2006 (CEST)

If you look from the users view you will find it quite uninteresting if a change in the product has got implemented via a patch or a direct commit into the code repository. From the products perspective important that you're able to track if functionality has changed or added. Even if you look for the contributors view the type FEATURE or ENHANCEMENT is essential: just by looking at the type of the issue you can see at glance, that more action than just applying the patch is needed:

• enhance existing test cases
• write new test or test plan
• change or write new documentation

--mh_ 06:12, 6 October 2006 (CEST)

These three points hold true for all issue types. Some of the surrounding work might be triggered by feature announcements for a PATCH the same way it would for other types. --stx12 20:57, 11 December 2006 (CET)