[Bug Sprint] The Boost bug sprint has begun!

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug Sprint] The Boost bug sprint has begun!

Marshall Clow-2
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Bug Sprint] The Boost bug sprint has begun!

Vicente Botet
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
Reply | Threaded
Open this post in threaded view
|

Re: [Bug Sprint] The Boost bug sprint has begun!

Marshall Clow-2
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Bug Sprint] The Boost bug sprint has begun!

Vicente Botet
In reply to this post by Marshall Clow-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [Bug Sprint] The Boost bug sprint has begun!

Jim Bell
In reply to this post by Marshall Clow-2

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?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Bug Sprint] The Boost bug sprint has begun!

Dean Michael Berris
On Mon, Nov 29, 2010 at 10:48 AM, Jim Bell <[hidden email]> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

[Bug Sprint] Policy on MIA maintainers

Jim Bell

(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 <[hidden email]> 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.




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Bug Sprint] Policy on MIA maintainers

Dean Michael Berris
On Mon, Nov 29, 2010 at 9:32 PM, Jim Bell <[hidden email]> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Bug Sprint] Policy on MIA maintainers

Jim Bell


On 1:59 PM, Dean Michael Berris wrote:
> On Mon, Nov 29, 2010 at 9:32 PM, Jim Bell <[hidden email]> 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>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Bug Sprint] Policy on MIA maintainers

Dean Michael Berris
On Sat, Dec 18, 2010 at 1:15 AM, Jim Bell <[hidden email]> wrote:

>
> On 1:59 PM, Dean Michael Berris wrote:
>> On Mon, Nov 29, 2010 at 9:32 PM, Jim Bell <[hidden email]> 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>
>

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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Bug Sprint] Policy on MIA maintainers

Jim Bell


On 1:59 PM, Dean Michael Berris wrote:

> On Sat, Dec 18, 2010 at 1:15 AM, Jim Bell <[hidden email]> wrote:
>> On 1:59 PM, Dean Michael Berris wrote:
>>> On Mon, Nov 29, 2010 at 9:32 PM, Jim Bell <[hidden email]> 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>
>>
> 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?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Bug Sprint] Policy on MIA maintainers

Dave Abrahams
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Bug Sprint] Policy on MIA maintainers

Vicente Botet
----- Original Message -----
From: "Dave Abrahams" <[hidden email]>
To: <[hidden email]>
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost