http://svn.boost.org/trac/boost/query?status=new&status=assigned&status=reopened&group=severity&milestone=Boost+1.35.0&order=priority shows all the tickets that have been assigned to the 1.35.0 milestone. Does this list have any meaning? In other words, are we actually intending to address all of these problems for 1.35, and put off other tickets for 1.35.1 or 1.36.0? IMO getting this list sorted out and handling the tickets one-by-one is the most productive way to get us from here to a successful release of 1.35.0. That may mean a number of new tickets need to be added (probably at least one for each major failure we're seeing in http://engineering.meta-comm.com/boost-regression/1_34_1/developer/issues.ht... and possibly others) and it will require part of the release team to triage the whole list of tickets assigned to 1.35.0 and make some decisions to put certain tickets off for later. Also, are we running complete tests on the release branch currently? I don't see any links to test results for that part of the repo. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Dave Abrahams wrote:
http://svn.boost.org/trac/boost/query?status=new&status=assigned&status=reopened&group=severity&milestone=Boost+1.35.0&order=priority shows all the tickets that have been assigned to the 1.35.0 milestone. Does this list have any meaning? In other words, are we actually intending to address all of these problems for 1.35, and put off other tickets for 1.35.1 or 1.36.0?
Personally, I'd like to see all the submitted patches "dealt with" for 1.35. Either apply them or reject them. [ There are about 50 outstanding patches ] Heck, there are still open patches assigned to the 1.34.1 milestone. -- -- 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 Tue Oct 30 2007, Marshall Clow <marshall-AT-idio.com> wrote:
Dave Abrahams wrote:
http://svn.boost.org/trac/boost/query?status=new&status=assigned&status=reopened&group=severity&milestone=Boost+1.35.0&order=priority shows all the tickets that have been assigned to the 1.35.0 milestone. Does this list have any meaning? In other words, are we actually intending to address all of these problems for 1.35, and put off other tickets for 1.35.1 or 1.36.0?
Personally, I'd like to see all the submitted patches "dealt with" for 1.35. Either apply them or reject them. [ There are about 50 outstanding patches ]
IMO another choice -- "put off 'till 1.36.0" -- is also reasonable.
Heck, there are still open patches assigned to the 1.34.1 milestone.
Those all need to have a milestone assigned. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Marshall Clow wrote:
Dave Abrahams wrote:
http://svn.boost.org/trac/boost/query?status=new&status=assigned&status=reopened&group=severity&milestone=Boost+1.35.0&order=priority shows all the tickets that have been assigned to the 1.35.0 milestone. Does this list have any meaning? In other words, are we actually intending to address all of these problems for 1.35, and put off other tickets for 1.35.1 or 1.36.0?
Personally, I'd like to see all the submitted patches "dealt with" for 1.35. Either apply them or reject them. [ There are about 50 outstanding patches ]
Patches seem a particularly high priority to me, too. I've reproduced the latest patch report from Marshall so we can all see who the guilty parties are:-) Developers, now is a great time to clear your outstanding patches! --Beman ------------------------------------------------------------------------------ [ 48 submitted patches today, 49 last week ] If you are maintaining a library, and have not logged into the trac system at <http://svn.boost.org/trac/boost/>, please do so ASAP. Until you do that, no tickets can be assigned to you, and will remain under "None". Instructions on working with tickets can be found at: <http://svn.boost.org/trac/boost/wiki/TicketWorkflow> and a mapping of user names to "real names" can be found at: <http://svn.boost.org/trac/boost/report/16> Patches 6 dave 5 rogeeff 4 nesotto 4 grafik 4 agurtovoy 4 None 3 turkanis 3 doug_gregor 2 djowel 2 az_sw_dude 2 anthonyw 1 urzuga 1 shammah 1 samuel_krempp 1 nasonov 1 jsiek 1 johnmaddock 1 dlwalker 1 danielw 1 bemandawes None 1116 disable some warnings in msvc build None 1182 Specifying character-set by the guideline and the inspect program None 1296 std::advance and std::distance for Boost.Iterator traversal categories None 1297 std advance and std distance for Boost.Iterator traversal categories agurtovoy 1049 Getting mpl/has_xxx.hpp to compile on AIX agurtovoy 637 Adjusts mpl::pair concept to be compatible with STL pairs agurtovoy 761 [mpl] evc4 port agurtovoy 861 Detect nested template members with has_template_xxx anthonyw 802 [thread] MSVS: Allow use of thread headers with /Za anthonyw 868 [thread] thread_specific_ptr::element_type ? az_sw_dude 1261 Boost.DateTime patch to support STLport's _STLP_NO_IOSTREAMS mode az_sw_dude 827 Unused variable in format date parser bemandawes 1090 scoped_file class that deletes file at end of scope danielw 863 [parameter] fix operator|| for lazy binding dave 1020 Boost.Iterator proposal to add is_constant_iterator dave 1066 Patch to make Boost.Python compile on SunCC dave 1271 unused parameter warning in release build dave 1316 Support for generic function(*args_ **kwds) call operator. dave 857 add shared_ptr< const T> support dave 903 inconsistent usage of function pointer typedefs djowel 1208 gcc initialization order warnings djowel 1313 Support multiple copyright lines in quickbook dlwalker 653 [integer] add support for integers longer than long doug_gregor 1087 Mismatch between BBv2 and bjam toolsets in configure script. doug_gregor 862 [utility] Make result_of handle lambda expressions doug_gregor 870 boost::graph::graph_utility.hpp is_connected() bad call grafik 1031 AmigaOS fixes for bjam grafik 1074 FreeBSD specific patches to boost 1.34.0 grafik 1287 Intel Compiler Patch for BJam's build.jam grafik 989 Boost build does not support building universal binaries on macintosh johnmaddock 633 [config] evc4 port jsiek 541 [concept_check.hpp] remove unused variable warning in msvc nasonov 839 lexical_cast - local variable shadow patch nesotto 1027 [ptr_container] optional serialization support nesotto 1151 [range] make_indirect_range() nesotto 1302 range test as_literal patch nesotto 1309 vc7.1 array workaround rogeeff 1169 errors in tutorial for test framework "new_year_resolution" rogeeff 645 [test] no eh exception handling functions on evc4 rogeeff 762 [test] evc4 issue with SEH support rogeeff 998 prg_exec_fail2 fail on ppc rogeeff 999 prg_exec_fail3 fails on release variant samuel_krempp 980 boost.format vc8/win32 compilation warning shammah 840 pool allocator - local variable shadow patch turkanis 586 iostreams // file_descriptor::seek BUG on files > 4 GB turkanis 869 [iostreams] patch for building by BBv2 turkanis 884 [iostreams] workaround for the boost + stdcxx on MSVC 7.1 urzuga 864 [lambda][utility] Make lambda support result<>
From: Jens Seidel
On Wed, Oct 31, 2007 at 02:56:45PM -0400, Beman Dawes wrote:
[ 48 submitted patches today, 49 last week ]
This message is misleading as it probably means that 48 patches are in the bug data base but *not* filed today. Maybe you should drop "today"?
I don't think the message is wrong. "submitted" is being used as an adjective to qualify "patches", not as a verb. It reads as: [There are] 48 submitted-patches today I think you are reading it as: 48 patches submitted today Which would be misleading. In that case "submitted" is a verb implying that all 48 patches were filed today. -- Martin Bonner Senior Software Engineer/Team Leader PI SHURLOK LTD Telephone: +44 1223 441434 / 203894 (direct) Fax: +44 1223 203999 Email: martin.bonner@pi-shurlok.com www.pi-shurlok.com disclaimer
On Thu, Nov 01, 2007 at 09:32:20AM -0000, Martin Bonner wrote:
From: Jens Seidel
On Wed, Oct 31, 2007 at 02:56:45PM -0400, Beman Dawes wrote:
[ 48 submitted patches today, 49 last week ]
This message is misleading as it probably means that 48 patches are in the bug data base but *not* filed today. Maybe you should drop "today"?
I don't think the message is wrong. "submitted" is being used as an
Maybe, but I'm no native speaker and interpreted it wrong. If it is possible to clarify it, why not? Jens
on Thu Nov 01 2007, Jens Seidel <jensseidel-AT-users.sf.net> wrote:
On Thu, Nov 01, 2007 at 09:32:20AM -0000, Martin Bonner wrote:
From: Jens Seidel
On Wed, Oct 31, 2007 at 02:56:45PM -0400, Beman Dawes wrote:
[ 48 submitted patches today, 49 last week ]
This message is misleading as it probably means that 48 patches are in the bug data base but *not* filed today. Maybe you should drop "today"?
I don't think the message is wrong. "submitted" is being used as an
Maybe, but I'm no native speaker and interpreted it wrong. If it is possible to clarify it, why not?
I agree. Even by a native speaker, it's easily interpreted as "we had 48 submitted patches today." Isn't it really the case that the number represents the number of "open" patch tickets? [ 48 open patch tickets yesterday, 49 last week ] Frankly I don't think we should be sending out a separate email about patches, because after all as Peter points out, they are all either bug fixes or feature requests, and just theoretically easier for the developer to apply. We probably shouldn't even have a separate category for patches. IMO they should all be sorted into one of the other categories. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
on Wed Oct 31 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Marshall Clow wrote:
Dave Abrahams wrote:
http://svn.boost.org/trac/boost/query?status=new&status=assigned&status=reopened&group=severity&milestone=Boost+1.35.0&order=priority shows all the tickets that have been assigned to the 1.35.0 milestone. Does this list have any meaning? In other words, are we actually intending to address all of these problems for 1.35, and put off other tickets for 1.35.1 or 1.36.0?
Personally, I'd like to see all the submitted patches "dealt with" for 1.35. Either apply them or reject them. [ There are about 50 outstanding patches ]
Patches seem a particularly high priority to me, too.
I've reproduced the latest patch report from Marshall so we can all see who the guilty parties are:-)
Developers, now is a great time to clear your outstanding patches!
IMO, promising patches that are merely new features that haven't been in testing for some time should be assigned to the 1.36.0 milestone rather than "cleared" by either integrating them or rejecting them. Patches should only be a high priority if they fix bugs... and in that case they should come with a test that breaks until the bug is fixed. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Wed Oct 31 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Marshall Clow wrote:
Dave Abrahams wrote:
http://svn.boost.org/trac/boost/query?status=new&status=assigned&status=reopened&group=severity&milestone=Boost+1.35.0&order=priority shows all the tickets that have been assigned to the 1.35.0 milestone. Does this list have any meaning? In other words, are we actually intending to address all of these problems for 1.35, and put off other tickets for 1.35.1 or 1.36.0? Personally, I'd like to see all the submitted patches "dealt with" for 1.35. Either apply them or reject them. [ There are about 50 outstanding patches ] Patches seem a particularly high priority to me, too.
I've reproduced the latest patch report from Marshall so we can all see who the guilty parties are:-)
Developers, now is a great time to clear your outstanding patches!
IMO, promising patches that are merely new features that haven't been in testing for some time should be assigned to the 1.36.0 milestone rather than "cleared" by either integrating them or rejecting them.
Yep. I was assuming patches were bug fixes, which may not be the case.
Patches should only be a high priority if they fix bugs... and in that case they should come with a test that breaks until the bug is fixed.
It is very useful and a sign of good software engineering if a test case accompanies a bug fix. But patch submitters don't always have enough time or knowledge of a library's test setup to submit test cases. I'd rather fixes be prioritized based on severity rather than whether or not they come with a test case. --Beman
Beman Dawes wrote:
It is very useful and a sign of good software engineering if a test case accompanies a bug fix. But patch submitters don't always have enough time or knowledge of a library's test setup to submit test cases. I'd rather fixes be prioritized based on severity rather than whether or not they come with a test case.
Fixing a bug without adding a test case is very shortsighted. It's not uncommon for bug fixes to be lost from release to release, and regressions to be introduced, both caused by insufficient test coverage. The main reason to submit a patch instead of just a bug report is to help the developer; if there's no test case in the patch, I'm not helped by it since I still need to do most of the work.
on Thu Nov 01 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
David Abrahams wrote:
on Wed Oct 31 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
David Abrahams wrote: Patches should only be a high priority if they fix bugs... and in that case they should come with a test that breaks until the bug is fixed.
It is very useful and a sign of good software engineering if a test case accompanies a bug fix. But patch submitters don't always have enough time or knowledge of a library's test setup to submit test cases. I'd rather fixes be prioritized based on severity rather than whether or not they come with a test case.
When I say "come with" I mean they should come into our source repository with a test case, which may be supplied by anyone, inlcuding the library maintainer. I don't think we should be just applying "bug fix" patches without being able to confirm that they actually fix bugs. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Thu Nov 01 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
on Wed Oct 31 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
David Abrahams wrote: Patches should only be a high priority if they fix bugs... and in that case they should come with a test that breaks until the bug is fixed. It is very useful and a sign of good software engineering if a test case accompanies a bug fix. But patch submitters don't always have enough time or knowledge of a library's test setup to submit test cases. I'd rather fixes be prioritized based on severity rather than whether or not
David Abrahams wrote: they come with a test case.
When I say "come with" I mean they should come into our source repository with a test case, which may be supplied by anyone, inlcuding the library maintainer. I don't think we should be just applying "bug fix" patches without being able to confirm that they actually fix bugs.
I don't know how to do that for system specific fixes on platforms Boost isn't testing and I don't have access to. For libraries like Boost.System and Boost.Filesystem I have to take such patches on faith. Of course I inspect them to make sure they appear reasonable and don't affect other platforms. What you are saying is certainly the "right way" most of the time. But it is hard to do for some of the more obscure platforms. --Beman
on Thu Nov 01 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
David Abrahams wrote:
on Thu Nov 01 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
on Wed Oct 31 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
David Abrahams wrote: Patches should only be a high priority if they fix bugs... and in that case they should come with a test that breaks until the bug is fixed. It is very useful and a sign of good software engineering if a test case accompanies a bug fix. But patch submitters don't always have enough time or knowledge of a library's test setup to submit test cases. I'd rather fixes be prioritized based on severity rather than whether or not
David Abrahams wrote: they come with a test case.
When I say "come with" I mean they should come into our source repository with a test case, which may be supplied by anyone, inlcuding the library maintainer. I don't think we should be just applying "bug fix" patches without being able to confirm that they actually fix bugs.
I don't know how to do that for system specific fixes on platforms Boost isn't testing and I don't have access to. For libraries like Boost.System and Boost.Filesystem I have to take such patches on faith. Of course I inspect them to make sure they appear reasonable and don't affect other platforms.
The person submitting the patch surely describes to you the problem the patch should be fixing, no? If you don't have access to the platform, create a test and tweak until it fails in the way described.
What you are saying is certainly the "right way" most of the time. But it is hard to do for some of the more obscure platforms.
I don't know; I guess I'd be very reluctant to patch my code with a correction for a problem until it's reproduced. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
From: David Abrahams
on Thu Nov 01 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
I don't know how to do that for system specific fixes on platforms Boost isn't testing and I don't have access to. For libraries like Boost.System and Boost.Filesystem I have to take such patches on faith. Of course I inspect them to make sure they appear reasonable and don't affect other platforms.
The person submitting the patch surely describes to you the problem the patch should be fixing, no?
If you don't have access to the platform, create a test and tweak until it fails in the way described.
I don't see how you can do that with system specific errors. Consider: "The foobarfs file system returns duff information if stat is called twice in succession on the same file. Fix by calling stat on /dev/null after each call to stat (unless calling stat on /dev/null, in which case call stat on / first.)" I don't see how you could possibly rig up a test case for that unless you have a system with foobarfs to hand. Alternatively, how about a compiler which won't accept valid code, but will accept some invalid code to perform the equivalent operation? How do you write a test case for that without the compiler? -- Martin Bonner Senior Software Engineer/Team Leader PI SHURLOK LTD Telephone: +44 1223 441434 / 203894 (direct) Fax: +44 1223 203999 Email: martin.bonner@pi-shurlok.com www.pi-shurlok.com disclaimer
on Mon Nov 05 2007, "Martin Bonner" <Martin.Bonner-AT-pi-shurlok.com> wrote:
From: David Abrahams
on Thu Nov 01 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
I don't know how to do that for system specific fixes on platforms Boost isn't testing and I don't have access to. For libraries like Boost.System and Boost.Filesystem I have to take such patches on faith. Of course I inspect them to make sure they appear reasonable and don't affect other platforms.
The person submitting the patch surely describes to you the problem the patch should be fixing, no?
If you don't have access to the platform, create a test and tweak until it fails in the way described.
I don't see how you can do that with system specific errors. Consider: "The foobarfs file system returns duff information if stat is called twice in succession on the same file. Fix by calling stat on /dev/null after each call to stat (unless calling stat on /dev/null, in which case call stat on / first.)"
I don't see how you could possibly rig up a test case for that unless you have a system with foobarfs to hand.
Okay, if it's not one of the configurations we're testing, you have a point.
Alternatively, how about a compiler which won't accept valid code, but will accept some invalid code to perform the equivalent operation? How do you write a test case for that without the compiler?
If you have a patch (that's the scenario), presumably you know what the invalid code workaround looks like. Anyway, I'm not trying to be an absolutist about this; it's just that I think the exceptions are very rare. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Here's another set of tickets that I think should be resolved (one way or another). Support Requests that are more than three years old (created before, say, 1/1/2005). If they haven't been resolved by now, I think they're probably not going to be resolved at all, and should be closed as "wontfix". #259 - Problem compiling :/ (jbandela) <http://svn.boost.org/trac/boost/ticket/259> Comment from Dave A (Jan 10, 2007): I'm assigning this to John Bandela, the token iterator author, in case he wants to take responsibility for it. However, it looks very much like a compiler bug (vc7 is rife with them) and if I were John I'd probably close it as "won't fix" because the compiler is two versions out-of-date and finding a workaround is likely to be difficult. #279 - SLOOOWW tokenizer compilation on VC++6.0 (jbandela) <http://svn.boost.org/trac/boost/ticket/279> Comment from Dave A (Jan 10, 2007): I'm assigning this to John Bandela, the tokenizer author, in case he wants to look at it. However, the issue and the compiler are both woefully out-of-date so I hope he'll just close the issue. #282 - boost::optional<enum> fails with /CLR (fcacciola) <http://svn.boost.org/trac/boost/ticket/282> Seen in the bug report: I'm using boost 1.31.0; this fails in both VC7.0 and VC7.1. BTW - I closed #306 as a duplicate of #259. -- -- 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 Mon Nov 05 2007, Marshall Clow <marshall-AT-idio.com> wrote:
Here's another set of tickets that I think should be resolved (one way or another). Support Requests that are more than three years old (created before, say, 1/1/2005).
If they haven't been resolved by now, I think they're probably not going to be resolved at all, and should be closed as "wontfix".
Feel free. As far as I'm concerned, you can close anything you think should be closed. Everybody that has ever edited the ticket gets an email when you do that, so if someone disagrees, they can just reopen it.
#259 - Problem compiling :/ (jbandela) <http://svn.boost.org/trac/boost/ticket/259> Comment from Dave A (Jan 10, 2007): I'm assigning this to John Bandela, the token iterator author, in case he wants to take responsibility for it. However, it looks very much like a compiler bug (vc7 is rife with them) and if I were John I'd probably close it as "won't fix" because the compiler is two versions out-of-date and finding a workaround is likely to be difficult.
#279 - SLOOOWW tokenizer compilation on VC++6.0 (jbandela) <http://svn.boost.org/trac/boost/ticket/279> Comment from Dave A (Jan 10, 2007): I'm assigning this to John Bandela, the tokenizer author, in case he wants to look at it. However, the issue and the compiler are both woefully out-of-date so I hope he'll just close the issue.
#282 - boost::optional<enum> fails with /CLR (fcacciola) <http://svn.boost.org/trac/boost/ticket/282> Seen in the bug report: I'm using boost 1.31.0; this fails in both VC7.0 and VC7.1.
BTW - I closed #306 as a duplicate of #259.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Also, are we running complete tests on the release branch currently? I don't see any links to test results for that part of the repo.
We are. You can see the links to them at <http://beta.boost.org/development/testing.html>. Although we have to wait until Beman gets back to have the release reports running again. We do need to decide which testers should be doing release regression tests. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
David Abrahams wrote:
http://svn.boost.org/trac/boost/query?status=new&status=assigned&status=reopened&group=severity&milestone=Boost+1.35.0&order=priority shows all the tickets that have been assigned to the 1.35.0 milestone. Does this list have any meaning? In other words, are we actually intending to address all of these problems for 1.35, and put off other tickets for 1.35.1 or 1.36.0?
IMO getting this list sorted out and handling the tickets one-by-one is the most productive way to get us from here to a successful release of 1.35.0. That may mean a number of new tickets need to be added (probably at least one for each major failure we're seeing in http://engineering.meta-comm.com/boost-regression/1_34_1/developer/issues.ht... and possibly others) and it will require part of the release team to triage the whole list of tickets assigned to 1.35.0 and make some decisions to put certain tickets off for later.
My original plan was to triage all outstanding trac tickets to identify those that really are important for 1.35.0, and then start pestering the owners. But so far I've spent all my time on test issues and failures. If you want to start triaging tickets and pestering people, feel free to go ahead and start that effort.
Also, are we running complete tests on the release branch currently? I don't see any links to test results for that part of the repo.
http://beta.boost.org/development/testing.html has links to both main trunk and release branch testing. Also smoke tests. --Beman
on Wed Oct 31 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
David Abrahams wrote:
http://svn.boost.org/trac/boost/query?status=new&status=assigned&status=reopened&group=severity&milestone=Boost+1.35.0&order=priority shows all the tickets that have been assigned to the 1.35.0 milestone. Does this list have any meaning? In other words, are we actually intending to address all of these problems for 1.35, and put off other tickets for 1.35.1 or 1.36.0?
IMO getting this list sorted out and handling the tickets one-by-one is the most productive way to get us from here to a successful release of 1.35.0. That may mean a number of new tickets need to be added (probably at least one for each major failure we're seeing in http://engineering.meta-comm.com/boost-regression/1_34_1/developer/issues.ht... and possibly others) and it will require part of the release team to triage the whole list of tickets assigned to 1.35.0 and make some decisions to put certain tickets off for later.
My original plan was to triage all outstanding trac tickets to identify those that really are important for 1.35.0, and then start pestering the owners.
But so far I've spent all my time on test issues and failures.
If you want to start triaging tickets and pestering people, feel free to go ahead and start that effort.
No, that wasn't my point. My point was that we should focus on making http://svn.boost.org/trac/boost/query?status=new&status=assigned&status=reopened&group=severity&milestone=Boost+1.35.0&order=priority (the list of tickets assigned to the 1.35.0 milestone) a meaningful report for this release. That means establishing a 1.36.0 milestone, declaring the criteria for including a ticket in 1.35.0, telling people that if they want an exception they have to get you to okay it, and maybe making any assignments of tickets to 1.35.0 and 1.36.0 that are obvious. Then we all have a list of issues to focus on killing off and we don't need to pester people as much. If you would like me to take on some of these tasks, please ask me. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
That means establishing a 1.36.0 milestone
There's no need to create such a milestone. I created the "To Be Determined" milestone. Which means that in addition to looking at the tickets currently in the 1.35.0 milestone we need to look through the ones in "To Be Determined" to see if any apply for this release. But ideally I would rather see the bug handling to occur entirely outside the 1.35.0 milestone since all the bugs should be getting fixed in the trunk, not the release. Hence as a gross approximation we would move all the 1.35.0 tickets to the "to be determined" milestone. And when a library is placed in the branch we can move the resolved tickets only to 1.35.0. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
on Mon Nov 05 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
David Abrahams wrote:
That means establishing a 1.36.0 milestone
There's no need to create such a milestone. I created the "To Be Determined" milestone.
Why is putting tickets in "to be determined" better than assigning them to 1.36.0 until such time as we decide to do something else with them? I don't like limbo.
Which means that in addition to looking at the tickets currently in the 1.35.0 milestone we need to look through the ones in "To Be Determined" to see if any apply for this release. But ideally I would rather see the bug handling to occur entirely outside the 1.35.0 milestone
What does that mean? No bugs should be labelled as "must be fixed for the release of 1.35?" How will we track our progress towards 1.35 releasability?
since all the bugs should be getting fixed in the trunk, not the release.
I don't understand what connection the area of the repository has with the milestone.
Hence as a gross approximation we would move all the 1.35.0 tickets to the "to be determined" milestone. And when a library is placed in the branch we can move the resolved tickets only to 1.35.0.
You're suggesting having all open tickets in "To be determined," and only assinging milestones after they're closed? That doesn't seem like a very good use of the technology. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Mon Nov 05 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
David Abrahams wrote:
That means establishing a 1.36.0 milestone There's no need to create such a milestone. I created the "To Be Determined" milestone.
Why is putting tickets in "to be determined" better than assigning them to 1.36.0 until such time as we decide to do something else with them? I don't like limbo.
How is "to be determined" any more limbo than a "1.36.0"? Unless you are guaranteeing that they will be addressed in the "1.36.0" release there's nothing informative in adding them to such a milestone IMO.
Which means that in addition to looking at the tickets currently in the 1.35.0 milestone we need to look through the ones in "To Be Determined" to see if any apply for this release. But ideally I would rather see the bug handling to occur entirely outside the 1.35.0 milestone
What does that mean?
I guess what I meant was that if one wants the "1.35.0" milestone to reflect the state of the release then it should include the issues addressed in the release branch. As opposed to reflect the issues addressed in the trunk.
No bugs should be labelled as "must be fixed for the release of 1.35?"
If there are such issues then yes they can be part of the milestone.
How will we track our progress towards 1.35 releasability?
As we agreed before... A release happens on the day the release is due and the release branch is clear. But since the point of the new procedures is to revert any breaking changes done to the release branch under most circumstances there should be no unresolved issues in the release. Only postponed issues.
since all the bugs should be getting fixed in the trunk, not the release.
I don't understand what connection the area of the repository has with the milestone.
I guess that's where we disagree. I see a connection as the 1.35.0 milestone defining what the release branch has in it.
Hence as a gross approximation we would move all the 1.35.0 tickets to the "to be determined" milestone. And when a library is placed in the branch we can move the resolved tickets only to 1.35.0.
You're suggesting having all open tickets in "To be determined," and only assinging milestones after they're closed? That doesn't seem like a very good use of the technology.
Perhaps. But this is sounding to me as just a semantic disagreement. You want to define the 1.35.0 milestone as the "prospective set of issues that may be part of the 1.35.0 release". And I prefer to define it as "the set of issues that are part of the 1.35.0 release". I don't actually care which definition one picks, and if the first one is a better use of milestones then the latter is fine. Just make sure to describe the milestone (in trac) to make it clear that it's a prospective determination. But I would still like to have some representation of what issues are address that are already part of the release branch. So maybe we need a new milestone just for that? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
You're suggesting having all open tickets in "To be determined," and only assinging milestones after they're closed? That doesn't seem like a very good use of the technology.
Perhaps. But this is sounding to me as just a semantic disagreement. You want to define the 1.35.0 milestone as the "prospective set of issues that may be part of the 1.35.0 release". And I prefer to define it as "the set of issues that are part of the 1.35.0 release". I don't actually care which definition one picks, and if the first one is a better use of milestones then the latter is fine. Just make sure to describe the milestone (in trac) to make it clear that it's a prospective determination. But I would still like to have some representation of what issues are address that are already part of the release branch. So maybe we need a new milestone just for that?
Why 1.35.0 milestone cannot be just list of issues that must be fixed for 1.35.0? Therefore, an issue can be marked closed only when it's fixed on trunk, and the fix is merged to branch. Am I missing something? - Volodya
Le jeudi 08 novembre 2007 à 10:01 -0600, Rene Rivera a écrit :
Perhaps. But this is sounding to me as just a semantic disagreement. You want to define the 1.35.0 milestone as the "prospective set of issues that may be part of the 1.35.0 release". And I prefer to define it as "the set of issues that are part of the 1.35.0 release". I don't actually care which definition one picks, and if the first one is a better use of milestones then the latter is fine. Just make sure to describe the milestone (in trac) to make it clear that it's a prospective determination. But I would still like to have some representation of what issues are address that are already part of the release branch. So maybe we need a new milestone just for that?
I have not followed the discussion closely, so I am probably missing something, but why a new milestone? Unless I'm mistaken, issues that are "fixed", "closed", and with a "1.35" milestone, are precisely issues that will be fixed in the release (unless the relevant patches are reverted). So I don't understand the need for a new milestone. Best regards, Guillaume
Guillaume Melquiond wrote:
I have not followed the discussion closely, so I am probably missing something, but why a new milestone? Unless I'm mistaken, issues that are "fixed", "closed", and with a "1.35" milestone, are precisely issues that will be fixed in the release (unless the relevant patches are reverted). So I don't understand the need for a new milestone.
For exactly the "unless the relevant patches are reverted" situation. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Le jeudi 08 novembre 2007 à 10:36 -0600, Rene Rivera a écrit :
I have not followed the discussion closely, so I am probably missing something, but why a new milestone? Unless I'm mistaken, issues that are "fixed", "closed", and with a "1.35" milestone, are precisely issues that will be fixed in the release (unless the relevant patches are reverted). So I don't understand the need for a new milestone.
For exactly the "unless the relevant patches are reverted" situation.
But your new milestone would not fix this issue either. If the milestone is set and if the patch is then reverted, whether the milestone is "1.35" or "really1.35" will not matter. It will be inaccurate in both cases. If someone takes care of removing the "really1.35" milestone when a patch is reverted, one could also take care of removing the "1.35" milestone. Best regards, Guillaume
Rene Rivera wrote:
Guillaume Melquiond wrote:
I have not followed the discussion closely, so I am probably missing something, but why a new milestone? Unless I'm mistaken, issues that are "fixed", "closed", and with a "1.35" milestone, are precisely issues that will be fixed in the release (unless the relevant patches are reverted). So I don't understand the need for a new milestone.
For exactly the "unless the relevant patches are reverted" situation.
Right: currently when something assigned to me was targeted for 1.35 I closed it once it was fixed in the Trunk: otherwise there's no way to tell what's been dealt with already :-) So I would actually be in favour of either a "pending merge to release" state, or else a new milestone for "1.35 Release Branch". Regards, John.
John Maddock wrote:
Rene Rivera wrote:
Guillaume Melquiond wrote:
I have not followed the discussion closely, so I am probably missing something, but why a new milestone? Unless I'm mistaken, issues that are "fixed", "closed", and with a "1.35" milestone, are precisely issues that will be fixed in the release (unless the relevant patches are reverted). So I don't understand the need for a new milestone. For exactly the "unless the relevant patches are reverted" situation.
Right: currently when something assigned to me was targeted for 1.35 I closed it once it was fixed in the Trunk: otherwise there's no way to tell what's been dealt with already :-)
So I would actually be in favour of either a "pending merge to release" state, or else a new milestone for "1.35 Release Branch".
After a bit of thinking... I thought it would optimally be good to have a ticket status to correspond to this. But it's not possible to change those in Trac. But there is one aspect we can use to describe the state, we can add a "Boost Release Branch" version, on par with the "Boost Development Trunk" version we have. So a ticket that is part of the 1.35.0 milestone can: * Be tagged as version "Boost Development Trunk" if it's only in the trunk, whether it's resolved or not. * Be tagged as version "Boost Release Branch" if it's been merged successfully to branches/release. But only if it's resolved in the trunk and verified to resolved in the release branch. I think that follows the new release procedures accurately. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
on Thu Nov 08 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
John Maddock wrote:
Rene Rivera wrote:
Guillaume Melquiond wrote:
I have not followed the discussion closely, so I am probably missing something, but why a new milestone? Unless I'm mistaken, issues that are "fixed", "closed", and with a "1.35" milestone, are precisely issues that will be fixed in the release (unless the relevant patches are reverted). So I don't understand the need for a new milestone. For exactly the "unless the relevant patches are reverted" situation.
Right: currently when something assigned to me was targeted for 1.35 I closed it once it was fixed in the Trunk: otherwise there's no way to tell what's been dealt with already :-)
So I would actually be in favour of either a "pending merge to release" state, or else a new milestone for "1.35 Release Branch".
After a bit of thinking... I thought it would optimally be good to have a ticket status to correspond to this. But it's not possible to change those in Trac.
Doug, can OSL please upgrade to Trac-0.11dev so we can have the ticket workflow feature? Thanks.
But there is one aspect we can use to describe the state, we can add a "Boost Release Branch" version, on par with the "Boost Development Trunk" version we have. So a ticket that is part of the 1.35.0 milestone can:
* Be tagged as version "Boost Development Trunk" if it's only in the trunk, whether it's resolved or not.
* Be tagged as version "Boost Release Branch" if it's been merged successfully to branches/release. But only if it's resolved in the trunk and verified to resolved in the release branch.
I think that follows the new release procedures accurately.
Well, the version field is traditionally for describing the version of the software in which the issue is being reported. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
on Thu Nov 08 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
David Abrahams wrote:
on Mon Nov 05 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
David Abrahams wrote:
That means establishing a 1.36.0 milestone There's no need to create such a milestone. I created the "To Be Determined" milestone.
Why is putting tickets in "to be determined" better than assigning them to 1.36.0 until such time as we decide to do something else with them? I don't like limbo.
How is "to be determined" any more limbo than a "1.36.0"? Unless you are guaranteeing that they will be addressed in the "1.36.0" release there's nothing informative in adding them to such a milestone IMO.
Assuming we use the system with any discipline, you are guaranteeing someone will have to look at them and make an explicit decision on their fate, at least w.r.t. 1.36.0, before it is released. "To be determined" tickets can be dealt with or ignored without any imperative deadline.
Which means that in addition to looking at the tickets currently in the 1.35.0 milestone we need to look through the ones in "To Be Determined" to see if any apply for this release. But ideally I would rather see the bug handling to occur entirely outside the 1.35.0 milestone
What does that mean?
I guess what I meant was that if one wants the "1.35.0" milestone to reflect the state of the release then it should include the issues addressed in the release branch. As opposed to reflect the issues addressed in the trunk.
IMO given the current release procedure, the right way to deal with that is to have a ticket state called "fixed in trunk" and another called "merged to release branch." I think that requires the ticket workflow feature, which means a Trac upgrade. Doug has said OSL is willing to do that if necessary.
No bugs should be labelled as "must be fixed for the release of 1.35?"
If there are such issues then yes they can be part of the milestone.
How will we track our progress towards 1.35 releasability?
As we agreed before... A release happens on the day the release is due and the release branch is clear.
So Trac is completely out of the loop as a tool for managing our progress? Seems like a collosal missed opportunity to me.
But since the point of the new procedures is to revert any breaking changes done to the release branch under most circumstances there should be no unresolved issues in the release. Only postponed issues.
since all the bugs should be getting fixed in the trunk, not the release.
I don't understand what connection the area of the repository has with the milestone.
I guess that's where we disagree. I see a connection as the 1.35.0 milestone defining what the release branch has in it.
Ticket workflow is the answer to that.
Hence as a gross approximation we would move all the 1.35.0 tickets to the "to be determined" milestone. And when a library is placed in the branch we can move the resolved tickets only to 1.35.0.
You're suggesting having all open tickets in "To be determined," and only assinging milestones after they're closed? That doesn't seem like a very good use of the technology.
Perhaps. But this is sounding to me as just a semantic disagreement. You want to define the 1.35.0 milestone as the "prospective set of issues that may be part of the 1.35.0 release".
No, I define it as the issues that we're currently declaring need to be dealt with before 1.35.0 can be released. That's the open issues. Which milestone closed issues are assigned to matters little.
And I prefer to define it as "the set of issues that are part of the 1.35.0 release".
That's a really odd way to approach issue tracking. You'll note that the vast majority of reports don't show closed tickets. That means most people are looking at the issues that are currently unresolved. Taking a milestone assignment off the table as a way of sorting and filtering open issues and relegating it to use with closed issues sacrifices a lot of expressivity and potentially useful information.
I don't actually care which definition one picks, and if the first one is a better use of milestones then the latter is fine.
IMO the first one is a better use of milestones and the latter is anything but fine.
Just make sure to describe the milestone (in trac) to make it clear that it's a prospective determination.
I'd lay dollars to donuts that you're an outlier in this: I can't believe that most experienced developers would be confused about the meaning of assinging an open ticket to a milestone.
But I would still like to have some representation of what issues are address that are already part of the release branch. So maybe we need a new milestone just for that?
Ticket workflow. :) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
My point was that we should focus on making http://svn.boost.org/trac/boost/query?status=new&status=assigned&status=reopened&group=severity&milestone=Boost+1.35.0&order=priority (the list of tickets assigned to the 1.35.0 milestone) a meaningful report for this release.
That means establishing a 1.36.0 milestone, declaring the criteria for including a ticket in 1.35.0, telling people that if they want an exception they have to get you to okay it, and maybe making any assignments of tickets to 1.35.0 and 1.36.0 that are obvious. Then we all have a list of issues to focus on killing off and we don't need to pester people as much.
If you would like me to take on some of these tasks, please ask me.
[dead silence since Monday] Am I really the only one that thinks this matters? I realize that as a project we don't have a lot of experience with effective use of bug and task tracking, but we also haven't been all that effective in the run-up to a release. Using the tools we have effectively can make a big difference. I'm only suggesting what most other projects I've seen do (including the Trac project) and it seems to work really well. There are all kinds of plugins we can install that will give us progress graphs, etc., but the builtin facilities of Trac are a good start. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
My point was that we should focus on making
(the list of tickets assigned to the 1.35.0 milestone) a meaningful report for this release.
That means establishing a 1.36.0 milestone, declaring the criteria for including a ticket in 1.35.0, telling people that if they want an exception they have to get you to okay it, and maybe making any assignments of tickets to 1.35.0 and 1.36.0 that are obvious. Then we all have a list of issues to focus on killing off and we don't need to pester people as much.
If you would like me to take on some of these tasks, please ask me.
[dead silence since Monday]
Am I really the only one that thinks this matters? I realize that as a project we don't have a lot of experience with effective use of bug and task tracking, but we also haven't been all that effective in the run-up to a release. Using the tools we have effectively can make a big difference.
FWIW - I think you're on the right track here. The bugs in this report are the ones that someone has decided "need to be dealt with" for this release, and so we, as a group, should resolve them. Some of these will be hard to resolve because the maintainer of a particular library has "gone walkabout", but we have been ducking that issue for a long time, too.
I'm only suggesting what most other projects I've seen do (including the Trac project) and it seems to work really well. There are all kinds of plugins we can install that will give us progress graphs, etc., but the builtin facilities of Trac are a good start.
I agree 100% -- -- 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 Thu Nov 08 2007, Marshall Clow <marshall-AT-idio.com> wrote:
My point was that we should focus on making
(the list of tickets assigned to the 1.35.0 milestone) a meaningful report for this release.
That means establishing a 1.36.0 milestone, declaring the criteria for including a ticket in 1.35.0, telling people that if they want an exception they have to get you to okay it, and maybe making any assignments of tickets to 1.35.0 and 1.36.0 that are obvious. Then we all have a list of issues to focus on killing off and we don't need to pester people as much.
If you would like me to take on some of these tasks, please ask me.
[dead silence since Monday]
Am I really the only one that thinks this matters? I realize that as a project we don't have a lot of experience with effective use of bug and task tracking, but we also haven't been all that effective in the run-up to a release. Using the tools we have effectively can make a big difference.
FWIW - I think you're on the right track here.
The bugs in this report are the ones that someone has decided "need to be dealt with" for this release,
I'm not so sure. I don't think we've been paying enough attention to guarantee that anyone really made a conscious decision about which milestone each issue should be in, so while the report above should be meaningful, I think it probably isn't meaningful yet. That means, IMO, that all open tickets should be reviewed for milestone assignment. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
on Thu Nov 08 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
on Thu Nov 08 2007, Marshall Clow <marshall-AT-idio.com> wrote:
My point was that we should focus on making
(the list of tickets assigned to the 1.35.0 milestone) a meaningful report for this release.
That means establishing a 1.36.0 milestone, declaring the criteria for including a ticket in 1.35.0, telling people that if they want an exception they have to get you to okay it, and maybe making any assignments of tickets to 1.35.0 and 1.36.0 that are obvious. Then we all have a list of issues to focus on killing off and we don't need to pester people as much.
If you would like me to take on some of these tasks, please ask me.
[dead silence since Monday]
Am I really the only one that thinks this matters? I realize that as a project we don't have a lot of experience with effective use of bug and task tracking, but we also haven't been all that effective in the run-up to a release. Using the tools we have effectively can make a big difference.
FWIW - I think you're on the right track here.
The bugs in this report are the ones that someone has decided "need to be dealt with" for this release,
I'm not so sure. I don't think we've been paying enough attention to guarantee that anyone really made a conscious decision about which milestone each issue should be in, so while the report above should be meaningful, I think it probably isn't meaningful yet.
That means, IMO, that all open tickets should be reviewed for milestone assignment.
It's even worse than that, as http://svn.boost.org/trac/boost/ticket/1079 shows, we have completely inconsistent practices as relates to the bug tracker. Some people actually close tickets that they plan to deal with later. That means we need to review even the closed tickets. If we want Boost-wide reports to make any sense, this confusion has to stop. We need a consistent set of practices that everyone will use to deal with tickets. I'll add some more "rules" to http://svn.boost.org/trac/boost/wiki/TicketWorkflow. These are, of course, negotiable, but I really hope nobody will negotiate too hard against them ;-). In the meantime, I've added a 1.36.0 milestone so anyone with a ticket they want to handle sometime down the road can the milestone to that. Regards, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams schrieb:
on Thu Nov 08 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
That means, IMO, that all open tickets should be reviewed for milestone assignment.
It's even worse than that, as http://svn.boost.org/trac/boost/ticket/1079 shows, we have completely inconsistent practices as relates to the bug tracker. Some people actually close tickets that they plan to deal with later. That means we need to review even the closed tickets.
Well, you set the milestone to 1.36.0 but still did not reopen the ticket. So everyone thinks it has been done already... Norbert
on Tue Dec 04 2007, Norbert Unterberg <nunterberg-AT-gmail.com> wrote:
David Abrahams schrieb:
on Thu Nov 08 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
That means, IMO, that all open tickets should be reviewed for milestone assignment.
It's even worse than that, as http://svn.boost.org/trac/boost/ticket/1079 shows, we have completely inconsistent practices as relates to the bug tracker. Some people actually close tickets that they plan to deal with later. That means we need to review even the closed tickets.
Well, you set the milestone to 1.36.0 but still did not reopen the ticket. So everyone thinks it has been done already...
Fixed, thanks -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
That means establishing a 1.36.0 milestone, declaring the criteria for including a ticket in 1.35.0, telling people that if they want an exception they have to get you to okay it, and maybe making any assignments of tickets to 1.35.0 and 1.36.0 that are obvious. Then we all have a list of issues to focus on killing off and we don't need to pester people as much.
If you would like me to take on some of these tasks, please ask me.
[dead silence since Monday]
Am I really the only one that thinks this matters? I realize that as a project we don't have a lot of experience with effective use of bug and task tracking, but we also haven't been all that effective in the run-up to a release. Using the tools we have effectively can make a big difference.
Violent agreement from here. We should also triage all the "Yet to be determined" bug reports as well, is there a way to get a report of all the bugs Trac issues that haven't been at least *looked at* yet? John.
on Thu Nov 08 2007, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
David Abrahams wrote:
That means establishing a 1.36.0 milestone, declaring the criteria for including a ticket in 1.35.0, telling people that if they want an exception they have to get you to okay it, and maybe making any assignments of tickets to 1.35.0 and 1.36.0 that are obvious. Then we all have a list of issues to focus on killing off and we don't need to pester people as much.
If you would like me to take on some of these tasks, please ask me.
[dead silence since Monday]
Am I really the only one that thinks this matters? I realize that as a project we don't have a lot of experience with effective use of bug and task tracking, but we also haven't been all that effective in the run-up to a release. Using the tools we have effectively can make a big difference.
Violent agreement from here.
We should also triage all the "Yet to be determined" bug reports as well, is there a way to get a report of all the bugs Trac issues that haven't been at least *looked at* yet?
Yes. And that's another good reason to keep the 1.36.0 milestone separate from the "TBD" milestone. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (11)
-
Beman Dawes -
David Abrahams -
Guillaume Melquiond -
Jens Seidel -
John Maddock -
Marshall Clow -
Martin Bonner -
Norbert Unterberg -
Peter Dimov -
Rene Rivera -
Vladimir Prus