Subject: Re: [boost] [Boost-users] Maintenace Guidelines wiki page
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2008-11-24 17:52:54
On Mon, Nov 24, 2008 at 9:33 AM, David Abrahams <dave_at_[hidden]> wrote:
> on Sun Nov 23 2008, "Daniel Walker" <daniel.j.walker-AT-gmail.com> wrote:
>>> One of the reasons Boost exists is to be more nimble than any
>>> committee (particularly the C++ standards committee) can be.
>> That's true, but at the same time, one goal of boost, as I've
>> understood it, is to establish existing practice, which could
>> eventually lead to inclusion in the standard library. So, yes, boost
>> should be more nimble than the ISO, but I think it should not be so
>> fluid as to make the peer review process meaningless and undermine
>> progress toward establishing best practices.
> Do you actually think the current peer review process is meaningless,
> due to the fluidity of our operations?
In general, no, but in this specific instance, yes. At least, the
Range concept definitions in the initial release immediately following
the formal review are richer and more useful, IMHO, than the
definitions available in the current release.
> I wish I could get someone to just start composing a page of best
> practices without jumping headlong into trying to impose constraints on
> our contributors. We haven't even tried making such guidelines
> available yet.
You're right. I just think of permissions on a version control system
as a tool, more than a negative constraint, so that's the first idea I
had. If more conservative changes to test cases are a result of
self-discipline, which I often lack ;), or if it's computer aided,
either way, it's probably a good thing.
> I guess I don't think it would be unreasonable to ask the release
> managers, as guardians of release quality, to monitor changes to the
> tests when they are checked into the release branch.
Yeah, that's a good idea. And as you suggested before, if SVN/Track
can help by sending e-mails, it might make the release manager's life
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk