Le 14/05/14 10:42, Neil Groves a écrit :
Dear Boost Developers,
While working with Trac to maintain Boost.Range I find that I frequently have solved issues but they are not ready to be merged to master due to the release schedule. I haven’t noticed a way in Trac to denote that the issue is fixed and waiting to be merged. This means that I frequently look up tickets that I have forgotten I have fixed. It also means that I have a sub-optimal process for merging to master.
I wondered if we might be able to squeeze in a “fixed in branch” field. It would help me considerably. Do other developers think this would help? Do you solve this in another, perhaps better way?
I’m happy to lend development time to get this done if there is consensus and we can risk me having write access to Trac code!
Hi, I set the milestone for the tickets that I'm working to empty when I accept them. I use to set the milestone of the ticket to the next release when I have added a fix on develop branch with the reference to the commit. With these two informations you can use a filter not-closed and Milestone<>1.56. When I merge it I just close it as fixed. I'm not against adding any state that helps to make this easier. I would like a flow that states clearly if the ticket is on a state that needs an action from the maintainer or the ticket creator. In this way it would be simpler to filter the tickets that we could work on. E.g. if I found that the ticket is not clear enough, I could change the ticket to the state request_for_information. The user should of course move to open when the information is provided. When I provide a patch that I can not test, I could move it to a state request_for_test. The user should of course move to tested when the pacth works for the user. HTH, Vicente