Hi, On 12/21/06, Tobias Bocanegra <[EMAIL PROTECTED]> wrote:
do we have a development/release management paper that describes the usual dev tasks?
See my recent messages along those lines, "Jira guidelines" from Nov 29th and "Future versions in Jira" from Dec 18th.
Q: What 'Fix Version' Should i choose when solving a bug?
See the emails I referred to above.
Q: When i fix an issue, should i 'resolve' or 'close' it?
"Resolve" it. There are two reasons not to "Close" it directly, one practical and one theoretical: practical: When preparing a release I try to fix issue metadata to make the Jira reports better. The metadata of a "Closed" issue can't be edited, so I need to explicitly reopen and then re-resolve it to make the metadata changes. theoretical: When you fix an issue, you've "resolved" it for yourself, but someone else might still have some problems with the fix. Only when the fix goes out in an official release should it be considered "closed". I'd even like to go as far as to mandate that "closed" issues should never be reopened as the released code can no longer be changed.
Q: During Codefreeze, do i need to commit changes to trunk and frozen branch?
Committing to trunk is always OK. Committing to a release branch is OK either if the release manager has explicitly OK'd it or if the issue implicitly qualifies for the branch as described in the "Fix Version" guidelines. It's also always OK *not* to commit changes to a release branch, as the release manager needs to in any case check for any pending changes in trunk that should go to a release. BR, Jukka Zitting
