----- Original Message ----- From: "Gennadiy Rozental" <rogeeff@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, March 25, 2010 5:29 PM Subject: Re: [boost] Library Maintainence - was 5 Observations ....
Robert Ramey <ramey <at> rrsd.com> writes:
Paul A. Bristow wrote:
If the maintainer appears missing (on holiday even), I'd favour quicker patching of bugs, after some discussion seeking agreement - or veto.
This would be a really bad idea in my opinion - for more than one reason.
I must say I agree with all of the Robert points. With "live" author/maintainer it should his or her responsibility to accept and/or apply patches/fixes.
I agree. But atleast the maintainer should respond to the requests in a reasonable time. Currently there are a lot of requests that are completly ignored if you don't insist quite often. See for example the report at <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=reopened&order=changetime&col=id&col=summary&col=component&col=status&col=type&col=owner&col=severity&col=changetime&type=!Feature+Requests>
For libraries with no maintainer around we either can obtain "communal" responsibility - which is not good IMO in almost all the cases or assign new maintainer, which might be acceptable but is not ideal IMO. The best approach IMO is to deprecate library immediately in next release, announce "contest" and "winner"/volunteer will rewrite library with the same API using the same unit tests (may or may not use existing implementation). If all the unit tests pass as a result, I do not see a need even for another review. Library reinstated in it's rights immediately.
I don't think that a new maintainer will reimplement the library completly at least not immediately. If the library pass already all the unit test, the library will be reinstated de facto. The problem is that we dont have unit tests to test the whether the ticket is a BUG or not. Vicente