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 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