Re: [boost] Maintenance Patches and cleaning up trac

Subject: Re: [boost] Maintenance Patches and cleaning up trac
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-05-21 12:41:23

_____________________
Vicente Juan Botet Escribá
http://viboes.blogspot.com/

----- Original Message ----- 
From: "Christopher Jefferson" <chris_at_[hidden]>
To: <boost_at_[hidden]>
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