[boost] Re: Who is the current maintainer of boost.thread?

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-01-29 11:58:14

Roland wrote:
> Some weeks ago Michael Glassford posted a question about
> the same subject. But as far as I can remeber without any
> answer. Did I miss something?

Not unless I missed it, too.

> Mike stated, that the original author silently disappeared from
> the list. The last relevant CVS commits have been done by a person
> named bill_kempf 11 months ago. Is this just a nickname
> for William Kempf?

Yes.

> I like to restate the question, and also would offer to spend
> some of my time for helping in maintainance of the
> thread library.

As I have already done also. Since then I've been familiarizing myself
with the parts of the Boost.Thread library I hadn't used yet, tracking
down discussions that would help me understand the decisions that were
made in the current version of the library, and looking at changes
that have already been added to thread_dev branch in CVS.

As I mentioned offlist to Roland this morning, I'm hoping after the
1.31.0 release happens to start moving newer Boost.Thread code that
already exists in the thread_dev branch to the main branch, eventually
including improved versions of new classes that exist there (such as
the read-write lock stuff) and maybe a couple submissions of my own
and others. At the same time I would hope to include fixes of any
known problems that haven't already been fixed in the thread_dev
branch.

It's worth mentioning that, as I'm not the owner or official
maintainer of the library, the approach I was hoping to take in doing
these things was first to discuss any significant proposed changes on
this list, then actually commit them to CVS only after consensus was
reached.

> The submission_process.htm page also deals with
> Lifecycle, and says: "If you no longer can or wish to
> maintain your library, please post a message on the Boost
> developers mailing list and help someone else take over as
> the library maintainer." Does this also imply, that the only way to
> deal with an obviously silent maintainer, is to submit a totally new
> review request for a replacement library to move on with an
otherwise
> stalled library?
>
> Regards,
> Roland

Mike