Echoing the logic: http://mail-archives.apache.org/mod_mbox/db-jdo-dev/200605.mbox/%3c447d2230.5020...@apache.org%3E
Anthony > On Nov 2, 2015, at 12:43 PM, John Blum <jb...@pivotal.io> wrote: > > +1 > > To add a bit of clarification on the Resolved vs. Closed status, you can > also think of Closed as the moment the customer/user considers the > issue/enhancement identified in the JIRA as complete and "accepted". Since > most OSS projects do not have a specific user/customer, then a ticket is > considered closed once released to indicate there were no additional follow > up on the ticket keeping it in an "in-progress" status and holding up the > release. This is not to say that a ticket cannot be "re-opened" at a later > time if another related problem is found. However, it usually up to > individual projects to decide whether to re-open the existing ticket or > just file a new one (and link back to the original). > > -j > > > On Mon, Nov 2, 2015 at 12:10 PM, Kirk Lund <kl...@pivotal.io> wrote: > >> Is there a standard that ASF follows for when a JIRA ticket changes status >> to Resolved vs Closed? >> >> If not, then I'd like recommend that we follow the process that Spring >> uses: >> >> Ticket changes to Resolved when the fix/implementation is committed or >> merged (to develop in our case). It then moves to Closed when that fix or >> implementation ships in a release. The two different states then have >> meaning and purpose as well as having a clear definition of when a ticket >> should be Resolved vs Closed. >> >> If a bug actually originates on a branch and is then Resolved on that same >> branch before merging anywhere, we could then specify that the ticket >> should be Closed before merging to develop. >> >> Thoughts or feedback? >> >> -Kirk >> > > > > -- > -John > 503-504-8657 > john.blum10101 (skype)
signature.asc
Description: Message signed with OpenPGP using GPGMail
