Herbert My gut feel is that it's fragile and unexpected to have tickets change status based on commit messages. Revisiting the ticket itself can remind you that the fix is only partial, or that there is another related ticket to look at, or that you need to add a regression test, or something else Too much automation can be confusing. I'd suggest (fairly strongly -- but resist if you feel otherwise) making status changes only based on explicit user actions. It doesn't take long to do! Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Simon | Marlow | Sent: 13 August 2013 13:17 | To: Herbert Valerio Riedel | Cc: ghc-devs@haskell.org | Subject: Re: New Git-commit-message -> Trac-ticket interaction | | On 10/08/13 10:57, Herbert Valerio Riedel wrote: | | > The command verbs currently recognized for referencing a ticket are | > currently: | > | > | addressing addresses re references refs see Trac | > | > ...and the verbs currently recognized for referencing *and* closing a | > ticket are | > | > | close closed closes fix fixed fixes | > | > Consequently, if you just write "Fixes Trac #1234" in your commit (which | > occurs quite often in the git history), this will only reference the | > ticket but *not* close the ticket. | > | > If closing from commits is not desired or causes problems, we can move | > the close/fix verbs into the "reference-only" set of verbs and be done | > with it. | | One reason that we didn't enable this feature before was that we often | want to move the ticket into the merge state after committing the fix. | | So perhaps we should either have a new keyword ("mergefix"?) for fixes | we want to merge, or we should not have the auto-close behaviour. | | Cheers, | Simon | | | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs