How to get bug reports addressed
I'm responsible for maintaining the local Boost install for a large group of developers, and I find myself spending an inordinate amount of time reapplying our local patches for Boost bugs every time a new version comes out, seemingly with no end in sight. One obvious example is https://svn.boost.org/trac/boost/ticket/3645: the report is clear and specific, documents a real bug, and provides a trivial patch which completely resolves the issue. It's everything one could possibly want in a bug report, and it has been utterly ignored for over a year. In my experience this has been the rule rather than the exception; other examples that I've been personally acquainted with include http://lists.boost.org/Archives/boost/2009/06/153214.php, https://svn.boost.org/trac/boost/ticket/4918, and https://svn.boost.org/trac/boost/ticket/4919. In every case the reporters have done everything they could to provide a useful bug report, up to and including providing patches, but have been met with profound silence. Does anyone have any suggestions for how to get action in these situations?
On Jan 6, 2011, at 2:22 PM, Geoffrey Romer wrote:
I'm responsible for maintaining the local Boost install for a large group of developers, and I find myself spending an inordinate amount of time reapplying our local patches for Boost bugs every time a new version comes out, seemingly with no end in sight. One obvious example is https://svn.boost.org/trac/boost/ticket/3645: the report is clear and specific, documents a real bug, and provides a trivial patch which completely resolves the issue. It's everything one could possibly want in a bug report, and it has been utterly ignored for over a year.
If Dave has no objection, I will be happy to take care of this.
In my experience this has been the rule rather than the exception; other examples that I've been personally acquainted with include http://lists.boost.org/Archives/boost/2009/06/153214.php, https://svn.boost.org/trac/boost/ticket/4918, and https://svn.boost.org/trac/boost/ticket/4919. In every case the reporters have done everything they could to provide a useful bug report, up to and including providing patches, but have been met with profound silence.
Same for 4918; I can apply this if it's ok with Jeremy. As for 4919, I see that the patch is not a complete fix; I'll have to look into it some more. Dave? Jeremy? -- Marshall
At Thu, 6 Jan 2011 15:09:08 -0800, Marshall Clow wrote:
On Jan 6, 2011, at 2:22 PM, Geoffrey Romer wrote:
I'm responsible for maintaining the local Boost install for a large group of developers, and I find myself spending an inordinate amount of time reapplying our local patches for Boost bugs every time a new version comes out, seemingly with no end in sight. One obvious example is https://svn.boost.org/trac/boost/ticket/3645: the report is clear and specific, documents a real bug, and provides a trivial patch which completely resolves the issue. It's everything one could possibly want in a bug report, and it has been utterly ignored for over a year.
If Dave has no objection, I will be happy to take care of this.
I have none.
In my experience this has been the rule rather than the exception; other examples that I've been personally acquainted with include http://lists.boost.org/Archives/boost/2009/06/153214.php, https://svn.boost.org/trac/boost/ticket/4918, and https://svn.boost.org/trac/boost/ticket/4919. In every case the reporters have done everything they could to provide a useful bug report, up to and including providing patches, but have been met with profound silence.
Same for 4918; I can apply this if it's ok with Jeremy. As for 4919, I see that the patch is not a complete fix; I'll have to look into it some more.
Dave? Jeremy?
Marshall, as far as I'm concerned you have earned the right to apply completely-obvious fixes to stagnant tickets without asking permission, and if I were in your shoes I wouldn't hesitate no matter who the putatively responsible maintainer is. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Fri, Jan 7, 2011 at 7:18 AM, Dave Abrahams <dave@boostpro.com> wrote:
Marshall, as far as I'm concerned you have earned the right to apply completely-obvious fixes to stagnant tickets without asking permission, and if I were in your shoes I wouldn't hesitate no matter who the putatively responsible maintainer is.
+1 Way to go Marshall! Your efforts are definitely most appreciated. PS. I have a list of patches too which would be nice to have applied or looked at as well, will send you an email off-list for those. :) -- Dean Michael Berris about.me/deanberris
Yes, please go ahead with the fixes. Best regards, Jeremy On Thu, Jan 6, 2011 at 4:18 PM, Dave Abrahams <dave@boostpro.com> wrote:
At Thu, 6 Jan 2011 15:09:08 -0800, Marshall Clow wrote:
On Jan 6, 2011, at 2:22 PM, Geoffrey Romer wrote:
I'm responsible for maintaining the local Boost install for a large group of developers, and I find myself spending an inordinate amount of time reapplying our local patches for Boost bugs every time a new version comes out, seemingly with no end in sight. One obvious example is https://svn.boost.org/trac/boost/ticket/3645: the report is clear and specific, documents a real bug, and provides a trivial patch which completely resolves the issue. It's everything one could possibly want in a bug report, and it has been utterly ignored for over a year.
If Dave has no objection, I will be happy to take care of this.
I have none.
In my experience this has been the rule rather than the exception; other examples that I've been personally acquainted with include http://lists.boost.org/Archives/boost/2009/06/153214.php, https://svn.boost.org/trac/boost/ticket/4918, and https://svn.boost.org/trac/boost/ticket/4919. In every case the reporters have done everything they could to provide a useful bug report, up to and including providing patches, but have been met with profound silence.
Same for 4918; I can apply this if it's ok with Jeremy. As for 4919, I see that the patch is not a complete fix; I'll have to look into it some more.
Dave? Jeremy?
Marshall, as far as I'm concerned you have earned the right to apply completely-obvious fixes to stagnant tickets without asking permission, and if I were in your shoes I wouldn't hesitate no matter who the putatively responsible maintainer is.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
-- ____________________________________ Jeremy Siek <jeremy.siek@colorado.edu> http://ecee.colorado.edu/~siek/ Assistant Professor Dept. of Electrical, Computer, and Energy Engineering University of Colorado at Boulder
On Thu, Jan 6, 2011 at 5:22 PM, Geoffrey Romer <gromer@google.com> wrote: I'm responsible for maintaining the local Boost install for a large group of
developers, and I find myself spending an inordinate amount of time reapplying our local patches for Boost bugs every time a new version comes out, seemingly with no end in sight.
I do understand the problem. It seems to me that this is exactly what Vendor Branches: http://svnbook.red-bean.com/en/1.1/ch07s05.html is intended to address. We've used that tactic fairly successfully ourselves. When a local patch is applied upstream and eventually arrives in your local repository, either the merge is trivial (because your local code is now identical to the vendor code) or you get a merge conflict, which you can resolve in favor of the new vendor code.
In every case the reporters have done everything they could to provide a useful bug report, up to and including providing patches, but have been met with profound silence.
But it's all volunteer effort. I'm impressed that Marshall responded as he did to your request.
On Fri, Jan 7, 2011 at 8:53 AM, Nat Linden <nat@lindenlab.com> wrote:
On Thu, Jan 6, 2011 at 5:22 PM, Geoffrey Romer <gromer@google.com> wrote:
I'm responsible for maintaining the local Boost install for a large group
of developers, and I find myself spending an inordinate amount of time reapplying our local patches for Boost bugs every time a new version comes out, seemingly with no end in sight.
I do understand the problem. It seems to me that this is exactly what Vendor Branches: http://svnbook.red-bean.com/en/1.1/ch07s05.html is intended to address. We've used that tactic fairly successfully ourselves.
When a local patch is applied upstream and eventually arrives in your local repository, either the merge is trivial (because your local code is now identical to the vendor code) or you get a merge conflict, which you can resolve in favor of the new vendor code.
Yeah, that's a good idea. Unfortunately, our local source control is not Subversion, and maintaining a local svn repository just for occasional Boost upgrades seems like overkill. There may be some way to get our source control to interoperate with svn in a way that will make this work, but if so, I haven't found it. One reasonable approximation to this approach would be if I could generate a patch file that takes one release version of Boost to the next; I could then apply that patch to perform the upgrade, and my local modifications would remain intact (except in the case of conflicts, which I can merge by hand). However, I haven't been able to work out how to identify a particular release version of Boost in the repository, in order to generate such a patch.
In every case the reporters have done everything they could to provide a useful bug report, up to and including providing patches, but have been met with profound silence.
But it's all volunteer effort. I'm impressed that Marshall responded as he did to your request.
I know it's a volunteer effort; that's why I've tried to do everything I can to minimize the workload on those volunteers, by providing detailed reports, patches, etc. Part of my frustration is that our voluntary efforts to give back to Boost were getting dropped on the floor, along with who knows how many others'. If I could check the fixes in myself, I would; I know it's not feasible to provide commit access to all and sundry, but the policy of granting commit access only to owners of particular libraries seems like it may be cutting Boost off from a useful pool of volunteers.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Fri, Jan 7, 2011 at 1:03 PM, Geoffrey Romer <gromer@google.com> wrote:
On Fri, Jan 7, 2011 at 8:53 AM, Nat Linden <nat@lindenlab.com> wrote:
On Thu, Jan 6, 2011 at 5:22 PM, Geoffrey Romer <gromer@google.com> wrote:
I find myself spending an inordinate amount of time reapplying our local
patches for Boost bugs every time a new version comes out, seemingly with no end in sight.
It seems to me that this is exactly what Vendor Branches: http://svnbook.red-bean.com/en/1.1/ch07s05.html is intended to address.
Yeah, that's a good idea. Unfortunately, our local source control is not Subversion, and maintaining a local svn repository just for occasional Boost upgrades seems like overkill. There may be some way to get our source control to interoperate with svn in a way that will make this work, but if so, I haven't found it.
? The technique doesn't seem to be specific to Subversion; it's about getting your revision-control system to merge, into your (locally-modified) trunk, the delta needed to update from the previous Boost version to the newer Boost version. Mercurial even has 'hg addremove', which looks to me like an improvement over svn_load_dirs.pl. One reasonable approximation to this approach would be if I could generate a
patch file that takes one release version of Boost to the next; I could then apply that patch to perform the upgrade, and my local modifications would remain intact (except in the case of conflicts, which I can merge by hand).
Yes, exactly!
However, I haven't been able to work out how to identify a particular release version of Boost in the repository, in order to generate such a patch.
Hmm, I'm not quite sure what you're saying here.
AMDG On 1/7/2011 10:03 AM, Geoffrey Romer wrote:
One reasonable approximation to this approach would be if I could generate a patch file that takes one release version of Boost to the next; I could then apply that patch to perform the upgrade, and my local modifications would remain intact (except in the case of conflicts, which I can merge by hand). However, I haven't been able to work out how to identify a particular release version of Boost in the repository, in order to generate such a patch.
That's easy:
svn ls http://svn.boost.org/svn/boost/tags/release Boost_0_7_0/ Boost_0_7_2/ Boost_0_7_8/ Boost_0_7_9/ Boost_0_8_1/ ... Boost_1_44_0/ Boost_1_44_0_beta1/ Boost_1_45_0/ Boost_1_45_0_beta1/
I know it's a volunteer effort; that's why I've tried to do everything I can to minimize the workload on those volunteers, by providing detailed reports, patches, etc. Part of my frustration is that our voluntary efforts to give back to Boost were getting dropped on the floor, along with who knows how many others'. If I could check the fixes in myself, I would; I know it's not feasible to provide commit access to all and sundry, but the policy of granting commit access only to owners of particular libraries seems like it may be cutting Boost off from a useful pool of volunteers.
If patches are in trac, they will be addressed eventually. The key word being eventually. In Christ, Steven Watanabe
participants (7)
-
Dave Abrahams -
Dean Michael Berris -
Geoffrey Romer -
Jeremy Siek -
Marshall Clow -
Nat Linden -
Steven Watanabe