Subject: Re: [boost] Trac request states - suggestion
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-05-19 19:01:00
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 havent 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?
> Im happy to lend development time to get this done if there is consensus and we can risk me having write access to Trac code!
I set the milestone for the tickets that I'm working to empty when I
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk