Trac request states - suggestion
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! Thanks, Neil Groves
On Wed, May 14, 2014 at 12:42 PM, Neil Groves
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 usually leave a message that the ticket is fixed in develop with a link to the commit. With Boost.Log I periodically merge develop into master and then close all those tickets. This way I'm sure I don't forget anything. It doesn't work well with cherry picking approach though. Maybe it is possible to create pull requests to merge individual commits from develop to master, but I didn't try. In any case, a new status would be useful at least to be able to filter such tickets.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Neil Groves Sent: 14 May 2014 09:43 To: boost@lists.boost.org Subject: [boost] Trac request states - suggestion
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?
Yes - I think states of 'fixed in develop' (awaiting possible user feedback?) 'fixed in master' branches (really believed fixed) 'fixed in release 1.xx' would be good. (fix has actually hit the streets) (Of course not having to remember to update would be even better but ...) Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830
On Wed, May 14, 2014 at 1:14 PM, Paul A. Bristow
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Neil Groves Sent: 14 May 2014 09:43 To: boost@lists.boost.org Subject: [boost] Trac request states - suggestion
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?
Yes - I think states of
'fixed in develop' (awaiting possible user feedback?)
'fixed in master' branches (really believed fixed)
'fixed in release 1.xx' would be good. (fix has actually hit the streets)
(Of course not having to remember to update would be even better but ...)
I think most people won't remember that. I certainly won't. :) I'd say 'fixed in release N' is only useful if it is set automatically for all tickets in 'fixed in master' by the release procedure (script?). Not sure if it's doable.
Date: Wed, 14 May 2014 13:21:03 +0400 From: andrey.semashev@gmail.com To: boost@lists.boost.org Subject: Re: [boost] Trac request states - suggestion
I think most people won't remember that. I certainly won't. :) I'd say 'fixed in release N' is only useful if it is set automatically for all tickets in 'fixed in master' by the release procedure (script?). Not sure if it's doable.
I think a fixed in develop state would be useful, but I don't think it needs to be more involved than that. The fixed state that already exists handles fixed in master and the release field handles which release it will be in.
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
participants (5)
-
Ahmed Charles -
Andrey Semashev -
Neil Groves -
Paul A. Bristow -
Vicente J. Botet Escriba