There's a serious problem with the Boost Community :(
Even though this is a complaint, let me start off by stating that I'm a happy user of Boost libraries for over six years, and don't intend to stop. That said, here's the problem: simple patches submitted languish without action or response for far too long. I submitted a patch for bjam with ticket #2552 back in November, including test cases to verify that it operates correctly. But despite requesting over several release cycles since then, no action has been taken and I haven't even gotten a response. It's a pain in the butt to have to keep reintegrating the same patch, release after release so I can keep working on code that I hope to one day submit to for inclusion in a Boost release. The Boost Community *really* needs a mechanism to ensure that patches submitted are acknowledged, vetted, and if found worthy, integrated into a release in a timely manner. Not doing so discourages contribution. Let me suggest that the Community set up something like the review queue, where a few volunteers could regularly select the next patch, request comments from the community and then champion getting the patch integrated into the next Boost release. I understand that library owners have a stake in the design vision and integrity of their library's code, so the community will have to figure out a policy where patches with minimal impact on a library's integrity can be quickly integrated without requiring a lot of the primary library owner's or maintainer's time, but will still get integrated or rejected in a timely manner. -- Jon Biggar jon@floorboard.com jon@biggar.org jonbiggar@gmail.com
The Boost Community *really* needs a mechanism to ensure that patches submitted are acknowledged, vetted, and if found worthy, integrated into a release in a timely manner. Not doing so discourages contribution.
Let me suggest that the Community set up something like the review queue, where a few volunteers could regularly select the next patch, request comments from the community and then champion getting the patch integrated into the next Boost release. I understand that library owners have a stake in the design vision and integrity of their library's code, so the community will have to figure out a policy where patches with minimal impact on a library's integrity can be quickly integrated without requiring a lot of the primary library owner's or maintainer's time, but will still get integrated or rejected in a timely manner. I sympathetize with you as it occured to me a few times. I think the
Jon Biggar wrote: main problem is mainly the lack of people and/or people's time to do so. There was a 'Trac Sprint' recently in which we tackled down around 120 tickets in a week. One of the question that arise from that was indeed the need to do this in a timely manner. Other point is the liability of the build process that, IIRC, prevent proper 'pacthes' to be shipped (Beman or Dave, correct me if I'm saying crap). Maybe the CMake effort will make this easier as a whole. All in all, if such a 'task force' is indeed needed, I'll gladly volunteer. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
joel wrote:
The Boost Community *really* needs a mechanism to ensure that patches submitted are acknowledged, vetted, and if found worthy, integrated into a release in a timely manner. Not doing so discourages contribution.
Let me suggest that the Community set up something like the review queue, where a few volunteers could regularly select the next patch, request comments from the community and then champion getting the patch integrated into the next Boost release. I understand that library owners have a stake in the design vision and integrity of their library's code, so the community will have to figure out a policy where patches with minimal impact on a library's integrity can be quickly integrated without requiring a lot of the primary library owner's or maintainer's time, but will still get integrated or rejected in a timely manner. I sympathetize with you as it occured to me a few times. I think the
Jon Biggar wrote: main problem is mainly the lack of people and/or people's time to do so. There was a 'Trac Sprint' recently in which we tackled down around 120 tickets in a week. One of the question that arise from that was indeed the need to do this in a timely manner. Other point is the liability of the build process that, IIRC, prevent proper 'pacthes' to be shipped (Beman or Dave, correct me if I'm saying crap).
I don't understand what you are saying above -- can you clarify? - Volodya
Jon Biggar wrote:
That said, here's the problem: simple patches submitted languish without action or response for far too long. I submitted a patch for bjam with ticket #2552 back in November, including test cases to verify that it operates correctly. But despite requesting over several release cycles since then, no action has been taken and I haven't even gotten a response. ... The Boost Community *really* needs a mechanism to ensure that patches submitted are acknowledged, vetted, and if found worthy, integrated into a release in a timely manner. Not doing so discourages contribution.
The fundamental matter is that "Boost Community", or rather "Boost Developers Community" does not exist. With 90 libraries, no single person has enough knowledge to apply patches to all of them. In fact, it's not even possible to have a single person oversee issue workflow, like ensuring response within specific time. This might be a problem, but frankly, no open-source project I worked with generally has such procedures, for similar reasons. I am afraid that the only way to guarantee a patch is in is to ping it if it's not applied after reasonable time. While you have pinged it once, recently, unfortunately the person the issue is assigned to was on vacation. - Volodya P.S. BTW, and this applies to everybody -- if you refer to an issue, please always include a description, like #1 (test issue). Referring just to issue number assumes that everybody remember what every issue is about.
Vladimir Prus wrote:
Jon Biggar wrote:
That said, here's the problem: simple patches submitted languish without action or response for far too long. I submitted a patch for bjam with ticket #2552 back in November, including test cases to verify that it operates correctly. But despite requesting over several release cycles since then, no action has been taken and I haven't even gotten a response. ... The Boost Community *really* needs a mechanism to ensure that patches submitted are acknowledged, vetted, and if found worthy, integrated into a release in a timely manner. Not doing so discourages contribution.
The fundamental matter is that "Boost Community", or rather "Boost Developers Community" does not exist. With 90 libraries, no single person has enough knowledge to apply patches to all of them. In fact, it's not even possible to have a single person oversee issue workflow, like ensuring response within specific time. This might be a problem, but frankly, no open-source project I worked with generally has such procedures, for similar reasons.
I am afraid that the only way to guarantee a patch is in is to ping it if it's not applied after reasonable time. While you have pinged it once, recently, unfortunately the person the issue is assigned to was on vacation.
Yep, being that person :-), I didn't notice the ping at all when I got back this week. And unfortunately I won't have time for much Boost related for some weeks, as I have this thing called "my wedding" to worry about next week ;-) But generally I agree that Boost has a problem as a meta-project. Even though it looks like *one* project from the outside it's not. And not managing it as one project is causing stuff to never get done. But this is the story of most open-source, so not sure if there's anything that can be done. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera wrote:
Yep, being that person :-), I didn't notice the ping at all when I got back this week. And unfortunately I won't have time for much Boost related for some weeks, as I have this thing called "my wedding" to worry about next week ;-)
But generally I agree that Boost has a problem as a meta-project. Even though it looks like *one* project from the outside it's not. And not managing it as one project is causing stuff to never get done. But this is the story of most open-source, so not sure if there's anything that can be done.
Perhaps library owners should recruit enough deputies who can be trusted to integrate patches to cover when the owner isn't available. -- Jon Biggar jon@floorboard.com jon@biggar.org jonbiggar@gmail.com
participants (4)
-
joel -
Jon Biggar -
Rene Rivera -
Vladimir Prus