Maintenance Patches and cleaning up trac
Having recent been browsing through boost trac I have noticed that it seems to be getting a little clogged with some very simple patches. Examples of simple patches: https://svn.boost.org/trac/boost/ticket/3402 - simple documentation patch, 6 months old, duplicated. https://svn.boost.org/trac/boost/ticket/3669 - add stdint.h to thread, fixes comeau, 6 months old. https://svn.boost.org/trac/boost/ticket/4060 - boost thread support for BOOST_NO_IOSTREAM I notice these 3 are in 'thread', and several others are in 'filesystem'. I do not wish to maintain these libraries myself, and it appears no-one else is coming forward to keep these libraries ticking over on a day-to-day basis. I would however personally be happy (possibly with help) to look at applying these patches, and applying the to trunk, and then release in time, assuming they pass regression testing. I would suggest a policy something like the following: 1) If a patch is considered to be "trivially obvious", mark the patch in trac, by leaving a comment, as a 'maintenance patch'. 2) If no-one disagrees within some period of time (2 weeks? 3?), then the patch is applied to trunk. If it passes regression testing it is then moved to release. Any thoughts on the topic? Chris
Christopher Jefferson <chris@bubblescope.net> writes:
https://svn.boost.org/trac/boost/ticket/3669 - add stdint.h to thread, fixes comeau, 6 months old.
That's actually a bug in Boost.Integer, so I've changed the assignment.
https://svn.boost.org/trac/boost/ticket/4060 - boost thread support for BOOST_NO_IOSTREAM
Fixed on trunk.
I notice these 3 are in 'thread', and several others are in 'filesystem'.
Only one of the 3 was actually in 'thread', but point taken --- I have got rather behind on handling trac issues. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
On 21 May 2010, at 16:29, Anthony Williams wrote:
Christopher Jefferson <chris@bubblescope.net> writes:
https://svn.boost.org/trac/boost/ticket/3669 - add stdint.h to thread, fixes comeau, 6 months old.
That's actually a bug in Boost.Integer, so I've changed the assignment.
https://svn.boost.org/trac/boost/ticket/4060 - boost thread support for BOOST_NO_IOSTREAM
Fixed on trunk.
I notice these 3 are in 'thread', and several others are in 'filesystem'.
Only one of the 3 was actually in 'thread', but point taken --- I have got rather behind on handling trac issues.
Apologises, I didn't want to single out any library in particular, I actually meant to take that sentence out before I sent the mail. Certainly some libraries keep more up to date than others, and some also get blamed for more things than others. With 982 open tickets, it is hard to keep track of all of trac. Perhaps just giving those responsible a little push is all it needs, rather than starting to apply patches at will. I might go through and do a full check of all the tickets marked 'patches', to see what status they all are, and report back.
_____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/ ----- Original Message ----- From: "Christopher Jefferson" <chris@bubblescope.net> To: <boost@lists.boost.org> Sent: Friday, May 21, 2010 4:52 PM Subject: [boost] Maintenance Patches and cleaning up trac
Having recent been browsing through boost trac I have noticed that it seems to be getting a little clogged with some very simple patches.
Examples of simple patches:
https://svn.boost.org/trac/boost/ticket/3402 - simple documentation patch, 6 months old, duplicated. https://svn.boost.org/trac/boost/ticket/3669 - add stdint.h to thread, fixes comeau, 6 months old. https://svn.boost.org/trac/boost/ticket/4060 - boost thread support for BOOST_NO_IOSTREAM
I notice these 3 are in 'thread', and several others are in 'filesystem'.
I will add these ones, as they are very simple. The problem is that there is no test that see the bug. #4238 timed_lock_upgrade(relative_time) calls timed_lock(absolute_time) #3748 condition_variable_any not non-copyable warning removal #3862 future.hpp - conversion from size_t to unsigned int #4076 future.hpp(411) : warning C4267: 'initializing' : conversion from 'size_t' to 'unsigned int', possible loss of data (duplicate of #3862 ??) #3883 "size_t to unsigned int" warning x64 MSVC 2008 (duplicate of #3862 ??) without patch, but very simple to correct. #3812 global namespace polution This one seems to be already on trunk #3231 boost::thread fails to compile with the sun CC compiler This seems to be released #2100 thread fails to compile with -fno-exceptions These ones seems to be invalid #3269 boost thread - mutex.lock() doesn't throw exception #3178 Sleep with negative time (clarify on the documentation) This is a very old ticket that comes recurrently #2330 thread::interrupt() can be lost if condition_variable::wait() in progress #3735 thread_group::interrupt_all() is unreliable #3960 condition_variable::timed_wait() cannot be interrupted
I do not wish to maintain these libraries myself, and it appears no-one else is coming forward to keep these libraries ticking over on a day-to-day basis. I would however personally be happy (possibly with help) to look at applying these patches, and applying the to trunk, and then release in time, assuming they pass regression testing.
I would suggest a policy something like the following:
1) If a patch is considered to be "trivially obvious", mark the patch in trac, by leaving a comment, as a 'maintenance patch'. 2) If no-one disagrees within some period of time (2 weeks? 3?), then the patch is applied to trunk. If it passes regression testing it is then moved to release.
Any thoughts on the topic?
I think that the author should not let tickets without response for more than 2 months. It is irritant to see tickets that the author have never added a comment. What about planning a Trac cleanup week as we did some months ago? (Note when we reached to decrease the number of tickets to 800, we have now 1008). Best, Vicente
On May 21, 2010, at 9:41 AM, vicente.botet wrote:
What about planning a Trac cleanup week as we did some months ago? (Note when we reached to decrease the number of tickets to 800, we have now 1008).
Vicente -- I'll be happy to set this up and encourage people, but the key driver is participation. Who is willing to contribute to another Boost Bug Sprint? [ Insert your name here ] 1) Marshall Clow (The first one was a resounding success; the second one much less so) -- Marshall P.S. How does June 5-13th work for everyone?
----- Original Message ----- From: "Marshall Clow" <mclow.lists@gmail.com> To: <boost@lists.boost.org> Sent: Friday, May 21, 2010 6:57 PM Subject: Re: [boost] Maintenance Patches and cleaning up trac
On May 21, 2010, at 9:41 AM, vicente.botet wrote:
What about planning a Trac cleanup week as we did some months ago? (Note when we reached to decrease the number of tickets to 800, we have now 1008).
Vicente --
I'll be happy to set this up and encourage people, but the key driver is participation.
Who is willing to contribute to another Boost Bug Sprint? [ Insert your name here ] 1) Marshall Clow
(The first one was a resounding success; the second one much less so)
-- Marshall
P.S. How does June 5-13th work for everyone?
OK for me. Vicente
Marshall Clow <mclow.lists@gmail.com> writes:
Who is willing to contribute to another Boost Bug Sprint? [ Insert your name here ] 1) Marshall Clow
Anthony Williams
P.S. How does June 5-13th work for everyone?
Sounds OK to me. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
On Fri, 21 May 2010, Anthony Williams wrote:
Marshall Clow <mclow.lists@gmail.com> writes:
Who is willing to contribute to another Boost Bug Sprint? [ Insert your name here ] 1) Marshall Clow
Anthony Williams
P.S. How does June 5-13th work for everyone?
Sounds OK to me.
It's fine with me too. Can I only fix up libraries that I "own" then, though? Most of the bugs in those are actually feature requests or things that are really hard to fix, and there seem to be some easy things in other libraries. -- Jeremiah Willcock
On May 21, 2010, at 12:32 PM, Jeremiah Willcock wrote:
On Fri, 21 May 2010, Anthony Williams wrote:
Marshall Clow <mclow.lists@gmail.com> writes:
Who is willing to contribute to another Boost Bug Sprint? [ Insert your name here ] 1) Marshall Clow
Anthony Williams
P.S. How does June 5-13th work for everyone?
Sounds OK to me.
It's fine with me too. Can I only fix up libraries that I "own" then, though? Most of the bugs in those are actually feature requests or things that are really hard to fix, and there seem to be some easy things in other libraries.
I would ask the maintainers of the other libraries. -- Marshall
On Fri, May 21, 2010 at 5:20 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
On May 21, 2010, at 12:32 PM, Jeremiah Willcock wrote:
On Fri, 21 May 2010, Anthony Williams wrote:
Marshall Clow <mclow.lists@gmail.com> writes:
Who is willing to contribute to another Boost Bug Sprint? [ Insert your name here ] 1) Marshall Clow
Anthony Williams
P.S. How does June 5-13th work for everyone?
Sounds OK to me.
It's fine with me too. Can I only fix up libraries that I "own" then, though? Most of the bugs in those are actually feature requests or things that are really hard to fix, and there seem to be some easy things in other libraries.
I would ask the maintainers of the other libraries.
I am not a maintainer of any of such libraries, but I will would be willing to help for anyone that needs it as well.
At Fri, 21 May 2010 15:32:27 -0400 (EDT), Jeremiah Willcock wrote:
It's fine with me too. Can I only fix up libraries that I "own" then, though? Most of the bugs in those are actually feature requests or things that are really hard to fix, and there seem to be some easy things in other libraries.
I follow a “fix first, ask questions later” policy :-) -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
What about planning a Trac cleanup week as we did some months ago? (Note when we reached to decrease the number of tickets to 800, we have now 1008).
Vicente --
I'll be happy to set this up and encourage people, but the key driver is participation.
Who is willing to contribute to another Boost Bug Sprint?
I might not be able to *sprint* as such, but I'll try and help out. John.
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
This one seems to be already on trunk #3231 boost::thread fails to compile with the sun CC compiler
Closed.
This seems to be released #2100 thread fails to compile with -fno-exceptions
Closed.
These ones seems to be invalid #3269 boost thread - mutex.lock() doesn't throw exception
Fixed on trunk.
#3178 Sleep with negative time (clarify on the documentation)
Fixed on trunk.
This is a very old ticket that comes recurrently #2330 thread::interrupt() can be lost if condition_variable::wait() in progress #3735 thread_group::interrupt_all() is unreliable #3960 condition_variable::timed_wait() cannot be interrupted
This one is a pain. I'm not sure how to fix it :-( Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Friday, May 21, 2010 7:14 PM Subject: Re: [boost] Maintenance Patches and cleaning up trac
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
This one seems to be already on trunk #3231 boost::thread fails to compile with the sun CC compiler
Closed.
This seems to be released #2100 thread fails to compile with -fno-exceptions
Closed.
These ones seems to be invalid #3269 boost thread - mutex.lock() doesn't throw exception
Fixed on trunk.
#3178 Sleep with negative time (clarify on the documentation)
Fixed on trunk.
Great. I was sure that once you toke a look at the Track system there will be a lot of Thread tickets that were closed.
This is a very old ticket that comes recurrently #2330 thread::interrupt() can be lost if condition_variable::wait() in progress #3735 thread_group::interrupt_all() is unreliable #3960 condition_variable::timed_wait() cannot be interrupted
This one is a pain. I'm not sure how to fix it :-(
#2330 propose something close to a solution. You can also change the documentation and state that wait doesn't a interruption point. Best, Vicente
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
From: "Anthony Williams" <anthony.ajw@gmail.com>
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
This is a very old ticket that comes recurrently #2330 thread::interrupt() can be lost if condition_variable::wait() in progress #3735 thread_group::interrupt_all() is unreliable #3960 condition_variable::timed_wait() cannot be interrupted
This one is a pain. I'm not sure how to fix it :-(
#2330 propose something close to a solution. You can also change the documentation and state that wait doesn't a interruption point.
I'll have a look at #2330 again then. I'd rather find a fix than lose wait() as an interruption point, but better that than have it broken. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
participants (8)
-
Anthony Williams -
Christopher Jefferson -
David Abrahams -
Jeremiah Willcock -
John Maddock -
Marshall Clow -
OvermindDL1 -
vicente.botet