
On Sat, Dec 18, 2010 at 1:15 AM, Jim Bell <Jim@jc-bell.com> wrote:
On 1:59 PM, Dean Michael Berris wrote:
On Mon, Nov 29, 2010 at 9:32 PM, Jim Bell <Jim@jc-bell.com> wrote:
I'd like someone to walk through a case study right here on the list. (Or a few people!) I'll take this up at a later time.
It's a later time. ;-)
Yes, alright. So just to see if I get the context right, a case study on what to do with an MIA maintainer is needed. I think Marshall Clow had successfully taken on the Boost.Array maintenance when the number of tickets filed against Boost.Array had piled up and the original maintainer didn't have the time to actively curate the tickets assigned the library. Basically what had to happen is: 1. Someone has to care enough to look at the tickets filed against a certain library that he either: a) Uses and depends on in his projects. b) Has enough time on his hands and a willingness to continue maintenance of a library. c) both, and potentially more reasons for caring. 2. That someone has to (in the current set-up) either: a) Address tickets by verifying whether they are issues or whether there are solutions not requiring changes to the library b) Submit patches to address the issues raised in the tickets c) Raise awareness of the issue on the mailing list to get the maintainer's attention d) Track down the maintainer (usually via email) to get him to respond at least to the ticket e) Go to BoostCon * and hope that the maintainer will be there to get him IRL ;) f) All of the above, and possibly other means to get changes into Boost by asking someone else with commit privileges to accept the patches 3. After doing the above, the contributor would usually be one or all of the below: a) Discouraged by the lack of maintenance on a given library b) Not try to contribute again because the cost of doing so is pretty high c) Choose to maintain a locally-patched version of Boost and just maintain that for the organization/himself (I've done this BTW before) d) Just wait for a time when Boost would be more open/responsive to contributions Case in point would be with the bug sprints -- some people try to be really active at that time, but either the maintainer has been busy (as some have already confessed) or there's no maintainer around to even respond to the tickets. If I'm not making sense with the points above, please take into consideration that I'm writing this as someone who's been trying to get patches to Boost in with varying levels of success. Thanks for the time and I hope this helps! (About recommendations, check the other thread about Open Source Forking, where I have a longer list of things I've shared about what I think should happen with the Boost development effort). -- Dean Michael Berris about.me/deanberris