Boost logo

Boost :

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á

----- 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:
> - simple documentation patch, 6 months old, duplicated.
> - add stdint.h to thread, fixes comeau, 6 months old.
> - 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).


Boost list run by bdawes at, gregod at, cpdaniel at, john at