[Bug Sprint] The Boost bug sprint has begun!
As of 7 AM PDT, there are 939 open bugs. [ I see that Vicente and Mattias have already started - that's great! ] General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010 General information about how the Trac system works is here: https://svn.boost.org/trac/boost/wiki/TicketWorkflow If you're looking for some way to contribute, I would suggest looking at the oldest active tickets, <https://svn.boost.org/trac/boost/report/1?sort=created&asc=1&page=1> and see if they are still valid. There are about 90 active tickets from 2005-2007. [ Many of them are feature requests, but there are bugs there too. ] Here are a couple of summary tables to give you an idea of where we are: https://svn.boost.org/trac/boost/report/20 Type Tickets Bugs 549 Feature Requests 250 Patches 99 Tasks 28 Support Requests 13 https://svn.boost.org/trac/boost/report/21 Milestone Tickets To Be Determined 352 Boost 1.43.0 102 Boost 1.44.0 98 Boost 1.42.0 75 Boost 1.36.0 50 Boost 1.40.0 48 Boost 1.39.0 44 <blank> 41 Boost 1.41.0 40 Boost 1.38.0 30 Boost 1.37.0 25 Boost-1.45.0 15 Boost-1.46.0 11 Website 1.X 4 Boost-1.47.0 1 Boost.Jam 3.1.18 1 Boost.Jam 4.0.0 1 https://svn.boost.org/trac/boost/report/19 Component Tickets date_time 61 thread 50 Python 48 filesystem 42 build 40 asio 38 mpl 38 smart_ptr 37 Useful reports: https://svn.boost.org/trac/boost/report/1 -- full list of tickets https://svn.boost.org/trac/boost/report/18 -- ticket counts by owner https://svn.boost.org/trac/boost/report/19 -- ticket counts by component https://svn.boost.org/trac/boost/report/20 -- ticket counts by ticket type https://svn.boost.org/trac/boost/report/21 -- ticket counts by milestone -- Marshall
Hi, There are 99 Patches now, this is a good starting point. It would be great if the authors/maintainers that want to participate to this Bug Sprint could check if the Patches are correct or not, and include them in trunk or change to BUG or Feature Request otherwise. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Bug-Sprint-The-Boost-bug-sprint-has-begun... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Nov 27, 2010, at 7:58 AM, Vicente Botet wrote:
There are 99 Patches now, this is a good starting point. It would be great if the authors/maintainers that want to participate to this Bug Sprint could check if the Patches are correct or not, and include them in trunk or change to BUG or Feature Request otherwise.
I've been looking at some of these patches, and I've found several (#1535m #4534, #3894, #2509) that have already been applied, and went out with the recent release (or even in previous releases). Those are easy tickets to close. ;-) -- Marshall
On 1:59 PM, Marshall Clow wrote:
On Nov 27, 2010, at 7:58 AM, Vicente Botet wrote:
There are 99 Patches now, this is a good starting point. It would be great if the authors/maintainers that want to participate to this Bug Sprint could check if the Patches are correct or not, and include them in trunk or change to BUG or Feature Request otherwise. I've been looking at some of these patches, and I've found several (#1535m #4534, #3894, #2509) that have already been applied, and went out with the recent release (or even in previous releases).
Those are easy tickets to close. ;-)
But what do we do for authors/maintainers NOT participating?
On Mon, Nov 29, 2010 at 10:48 AM, Jim Bell <Jim@jc-bell.com> wrote:
On 1:59 PM, Marshall Clow wrote:
On Nov 27, 2010, at 7:58 AM, Vicente Botet wrote:
There are 99 Patches now, this is a good starting point. It would be great if the authors/maintainers that want to participate to this Bug Sprint could check if the Patches are correct or not, and include them in trunk or change to BUG or Feature Request otherwise. I've been looking at some of these patches, and I've found several (#1535m #4534, #3894, #2509) that have already been applied, and went out with the recent release (or even in previous releases).
Those are easy tickets to close. ;-)
But what do we do for authors/maintainers NOT participating?
Good question. I think for the meantime the best we can do is keep sending in patches and bugging the maintainers to either look at the patches. Until we get to a consensus on how to deal with inactive maintainers, I guess we can only play by the same rules in the meantime. If someone is willing to step up as a maintainer of a library please don't hesitate to express your interest to the maintainer of the library you wish to maintain. Getting a maintainer's nod should be alright as a go-ahead for the SVN administrators to give commit access to whoever volunteers that the original maintainer "anoints". Aside from that, really all we can do is look at issues that seem to have been neglected, and just keep at it until either: 1. The maintainers grant commit access to those who really want to contribute and co-maintain the library, or... 2. The maintainers actually apply the patches and close the issues. Either way we'll get the job done IMO. :) -- Dean Michael Berris deanberris.com
(Was "Re: [boost] [Bug Sprint] The Boost bug sprint has begun!") On 1:59 PM, Dean Michael Berris wrote:
On Mon, Nov 29, 2010 at 10:48 AM, Jim Bell <Jim@jc-bell.com> wrote:
On 1:59 PM, Marshall Clow wrote:
On Nov 27, 2010, at 7:58 AM, Vicente Botet wrote:
There are 99 Patches now, this is a good starting point. It would be great if the authors/maintainers that want to participate to this Bug Sprint could check if the Patches are correct or not, and include them in trunk or change to BUG or Feature Request otherwise. [...] But what do we do for authors/maintainers NOT participating?
Good question.
I think for the meantime the best we can do is keep sending in patches and bugging the maintainers to either look at the patches. Until we get to a consensus on how to deal with inactive maintainers, I guess we can only play by the same rules in the meantime.
I think now's the time to get that consensus, or start the process. (And, of course, I'm thinking about Boost.Guild.) I'd like someone to walk through a case study right here on the list. (Or a few people!) Pick an un(der)-maintained library. (Most open patches/tickets?) Assume you're not an expert on that library. Pick one of the submitted patches at random: Now review it yourself: * Would you incorporate it? * What's your level of confidence? * Should the trunk regression tests get a shot at it? How much time did you spend reaching your conclusions?
If someone is willing to step up as a maintainer of a library please don't hesitate to express your interest to the maintainer of the library you wish to maintain. Getting a maintainer's nod should be alright as a go-ahead for the SVN administrators to give commit access to whoever volunteers that the original maintainer "anoints".
Aside from that, really all we can do is look at issues that seem to have been neglected, and just keep at it until either:
1. The maintainers grant commit access to those who really want to contribute and co-maintain the library, or... 2. The maintainers actually apply the patches and close the issues.
Either way we'll get the job done IMO. :)
If a maintainer is MIA, I say "we" apply the patches. One or more people look at a patch, mark the ticket as recommended, and/or put it on the list of patches for someone with SVN permissions to apply. Or mark it as NOT recommended, and close the ticket.
On Mon, Nov 29, 2010 at 9:32 PM, Jim Bell <Jim@jc-bell.com> wrote:
(Was "Re: [boost] [Bug Sprint] The Boost bug sprint has begun!")
On 1:59 PM, Dean Michael Berris wrote:
I think for the meantime the best we can do is keep sending in patches and bugging the maintainers to either look at the patches. Until we get to a consensus on how to deal with inactive maintainers, I guess we can only play by the same rules in the meantime.
I think now's the time to get that consensus, or start the process. (And, of course, I'm thinking about Boost.Guild.)
I don't think it's worth holding up the sprint for it was what I meant. Some of us have other things to do than just try to get consensus about what to do with MIA maintainers. ;) That said, I think it's an important conversation to be had. Although I still think that contacting the maintainers and getting their approval to give someone commit privileges or make someone more active a co-maintainers would be easier than making a policy in general.
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. [snip]
Aside from that, really all we can do is look at issues that seem to have been neglected, and just keep at it until either:
1. The maintainers grant commit access to those who really want to contribute and co-maintain the library, or... 2. The maintainers actually apply the patches and close the issues.
Either way we'll get the job done IMO. :)
If a maintainer is MIA, I say "we" apply the patches. One or more people look at a patch, mark the ticket as recommended, and/or put it on the list of patches for someone with SVN permissions to apply. Or mark it as NOT recommended, and close the ticket.
The problem with that is who the "we" are, and what the maintainer's job will actually be if he can be vetoed by who the "we" are. The reason a person is the maintainer is because he has agreed that he will maintain the library and support it across releases of the library. Applying patches that are deemed suitable is that person's responsibility. If someone is willing to step up in helping in the effort, he has to be anointed by the maintainer, no way around it IMO. Now if it's an issue of getting more people to help with cleaning up or addressing issues, I don't think that needs any permission from the maintainer. In the case of the MIA maintainer, getting the person's agreement to share the maintenance duties with someone else would be better than making it a "free for all" or for making a special class of developers that will get that privilege of committing to the repository. I'd say we deal with it on a case to case basis and not go into the putting too much policy in place. -- Dean Michael Berris deanberris.com
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. ;-) <http://lists.boost.org/Archives/boost/2010/11/173547.php>
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
On 1:59 PM, Dean Michael Berris wrote:
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.
Again, thanks for the thoughtful reply. But I'm thinking something much less ambitious. (And more measurable.) How about this question: as of this moment, we have X number of patches already in Trac. What's the average quality of those patches? (If a library has diverged from a patch, don't count it, as that's not fair to the patch.) See where I'm going? If 97% of existing patches would be accepted, how much apprehension should you have about the next one? (Or if only 40%...) Or, if a Boost-trusted developer not intimately familiar with the library can, in two minutes (or ten? twenty?) determine that the patch is valid, with 97% accuracy, what would that mean? And if the patch had to do directly with a regression failure, how would that change things?
At Sat, 18 Dec 2010 10:39:34 -0600, Jim Bell wrote:
How about this question: as of this moment, we have X number of patches already in Trac. What's the average quality of those patches? (If a library has diverged from a patch, don't count it, as that's not fair to the patch.)
See where I'm going? If 97% of existing patches would be accepted, how much apprehension should you have about the next one? (Or if only 40%...)
Or, if a Boost-trusted developer not intimately familiar with the library can, in two minutes (or ten? twenty?) determine that the patch is valid, with 97% accuracy, what would that mean?
And if the patch had to do directly with a regression failure, how would that change things?
Many of the patches I've seen come in seem to be perfectly good code but lack docs and tests. How should we classify those? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
----- Original Message ----- From: "Dave Abrahams" <dave@boostpro.com> To: <boost@lists.boost.org> Sent: Saturday, December 18, 2010 8:07 PM Subject: Re: [boost] [Bug Sprint] Policy on MIA maintainers
Many of the patches I've seen come in seem to be perfectly good code but lack docs and tests. How should we classify those?
I would say that an incomplete patch must be reclasified as a Bug or Feature request depending on what was initialy. I've done this for incomplete patches already. Vicente
Hi, The following Boost.Thread minor Tickets contains a patch that seems correct to me. #4819 boost.thread's documentation misprints #3975 Incorrect precondition for promise::set_wait_callback() #2639 documentation should be extended #3885 document about mix usage of boost.thread and native thread api #4315 gcc 4.4 Warning: inline ... declared as dllimport: attribute ignored #3762 Thread can't be compiled with winscw (Codewarrior by Nokia) #4818 Fix for warning on unused variable in boost/thread/pthread/condition_variable.hpp This one needs just to remove one of the duplicated files. #3160 Duplicate tutorial code in boost::thread I think that this one can be closed: #4773 boost::this_thread::sleep(Microsecond Resolution) new Feature Requests To Be Determined 3 weeks Anthony, could you check them to see if they can be included in trunk? This could reduce the # of Thread tickets by 10. Of course there are other tickets that seems much more critical, most of them related to move semantics, tss, 64 bits, ... I will see if I can provide a patch for these ones which seems not too complex: #4048 thread::id formatting involves locale #2575 Bug- Boost 1.36.0 on Itanium platform #4533 timespec translation fails for times before 1970 Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Bug-Sprint-The-Boost-bug-sprint-has-begun... Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (6)
-
Dave Abrahams -
Dean Michael Berris -
Jim Bell -
Marshall Clow -
Vicente Botet -
vicente.botet