[Bug Sprint] Anyone familiar with the utility library want to try bug #2285?
Writing some docs for "unwrap_ref". https://svn.boost.org/trac/boost/ticket/2585 -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
AMDG Marshall Clow wrote:
Writing some docs for "unwrap_ref". https://svn.boost.org/trac/boost/ticket/2585
It's documented in the trunk but not the release branch--which is okay because unwrap_ref itself has not been merged to the release branch. In Christ, Steven Watanabe
on Tue Jun 02 2009, Steven Watanabe <watanabesj-AT-gmail.com> wrote:
AMDG
Marshall Clow wrote:
Writing some docs for "unwrap_ref". https://svn.boost.org/trac/boost/ticket/2585
It's documented in the trunk but not the release branch--which is okay because unwrap_ref itself has not been merged to the release branch.
Sheesh! It probably should be, no? I guess "merge to release" is another thing we need to get into our ticket workflow. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
At 12:33 PM -0400 6/3/09, David Abrahams wrote:
on Tue Jun 02 2009, Steven Watanabe <watanabesj-AT-gmail.com> wrote:
AMDG
Marshall Clow wrote:
Writing some docs for "unwrap_ref". https://svn.boost.org/trac/boost/ticket/2585
It's documented in the trunk but not the release branch--which is okay because unwrap_ref itself has not been merged to the release branch.
Sheesh! It probably should be, no?
I guess "merge to release" is another thing we need to get into our ticket workflow.
Here's a proposal: 1) We add a new ticket type "Merge to release". 2) When you fix a bug in the trunk, instead of closing it as "fixed", you change it to "Merge to release". 3) After the tests have cycled for a while, and you are confident of the fix, you mark the bug as "fixed". Advantages: 1) We can track bugs that are fixed in trunk, but not yet in release. 2) People interested in the bug can test it in trunk. Disadvantages: 1) More complexity in the bug flow "process". Comments? -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
At 10:31 AM -0700 6/3/09, Marshall Clow wrote:
At 12:33 PM -0400 6/3/09, David Abrahams wrote:
on Tue Jun 02 2009, Steven Watanabe <watanabesj-AT-gmail.com> wrote:
AMDG
Marshall Clow wrote:
Writing some docs for "unwrap_ref". https://svn.boost.org/trac/boost/ticket/2585
It's documented in the trunk but not the release branch--which is okay because unwrap_ref itself has not been merged to the release branch.
Sheesh! It probably should be, no?
I guess "merge to release" is another thing we need to get into our ticket workflow.
Here's a proposal:
1) We add a new ticket type "Merge to release". 2) When you fix a bug in the trunk, instead of closing it as "fixed", you change it to "Merge to release". 3) After the tests have cycled for a while, and you are confident of the fix, you mark the bug as "fixed".
Oops - left out a bit: 3) After the tests have cycled for a while, and you are confident of the fix, you merge the changes to the release branch and mark the bug as "fixed". -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
on Wed Jun 03 2009, Marshall Clow <marshall-AT-idio.com> wrote:
At 10:31 AM -0700 6/3/09, Marshall Clow wrote:
At 12:33 PM -0400 6/3/09, David Abrahams wrote:
on Tue Jun 02 2009, Steven Watanabe <watanabesj-AT-gmail.com> wrote:
AMDG
Marshall Clow wrote:
Writing some docs for "unwrap_ref". https://svn.boost.org/trac/boost/ticket/2585
It's documented in the trunk but not the release branch--which is okay because unwrap_ref itself has not been merged to the release branch.
Sheesh! It probably should be, no?
I guess "merge to release" is another thing we need to get into our ticket workflow.
Here's a proposal:
1) We add a new ticket type "Merge to release". 2) When you fix a bug in the trunk, instead of closing it as "fixed", you change it to "Merge to release". 3) After the tests have cycled for a while, and you are confident of the fix, you mark the bug as "fixed".
Oops - left out a bit: 3) After the tests have cycled for a while, and you are confident of the fix, you merge the changes to the release branch and mark the bug as "fixed".
Which should also be doable with the post-commit hook. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Wed Jun 03 2009, Marshall Clow <marshall-AT-idio.com> wrote:
At 12:33 PM -0400 6/3/09, David Abrahams wrote:
on Tue Jun 02 2009, Steven Watanabe <watanabesj-AT-gmail.com> wrote:
AMDG
Marshall Clow wrote:
Writing some docs for "unwrap_ref". https://svn.boost.org/trac/boost/ticket/2585
It's documented in the trunk but not the release branch--which is okay because unwrap_ref itself has not been merged to the release branch.
Sheesh! It probably should be, no?
I guess "merge to release" is another thing we need to get into our ticket workflow.
Here's a proposal:
1) We add a new ticket type "Merge to release".
You must mean "status," not "type," right?
2) When you fix a bug in the trunk, instead of closing it as "fixed", you change it to "Merge to release".
Yeah, we need to update our post-commit hook to recognize "fixed" on trunk changes and do that instead of closing the ticket.
3) After the tests have cycled for a while, and you are confident of the fix, you mark the bug as "fixed".
Good.
Advantages: 1) We can track bugs that are fixed in trunk, but not yet in release. 2) People interested in the bug can test it in trunk.
Disadvantages: 1) More complexity in the bug flow "process".
Comments?
We *need* more complexity. We haven't got enough expressivity right now to do anything useful for our workflow. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
2009/6/3 David Abrahams <dave@boostpro.com>:
on Wed Jun 03 2009, Marshall Clow <marshall-AT-idio.com> wrote:
2) When you fix a bug in the trunk, instead of closing it as "fixed", you change it to "Merge to release".
Yeah, we need to update our post-commit hook to recognize "fixed" on trunk changes and do that instead of closing the ticket.
It'll also need to understand the website repository - so bugs are 'fixed on trunk' for 'website/public_html/beta' changes and fixed properly for 'website/public_html/live'. Who should the feature request be assigned to? Daniel
participants (4)
-
Daniel James -
David Abrahams -
Marshall Clow -
Steven Watanabe