Boost logo

Boost :

Subject: Re: [boost] Moving wiki/Guidelines/WarningsGuidelines
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2018-08-02 08:42:56

On 2018-08-02 04:18 AM, Mateusz Loskot via Boost wrote:

> On 2 August 2018 at 10:09, Stefan Seefeld via Boost
> <boost_at_[hidden]> wrote:
>> On 2018-08-02 03:59 AM, Mateusz Loskot via Boost wrote:
>>> Paul Bristow suggested [1]
>>> "We might also re-host this document somewhere on github/boostorg?"
>>> [1]
>>> I'd like to edit and move the wiki page away from Trac.
>>> IMHO, it is reasonable to host it not on GitHub wiki but
>>> on along other guidelines, for example, at
>>> - It is easy to update website via pull requests.
>>> - Any updates would be a subject of some review at least
>>> Thoughts? Objections?
>> I don't think this is a good idea, as it contributes to the proliferation of
>> locations to look for to find information (or to contribute updates), which
>> will also result in duplicate (in the best case) or contradictory (in the
>> worst case) information.
> You've lost me.
> I'm suggesting *single* place to maintain all the common Boost development
> guidelines, namely
>> Ideally, should consist of a *very* small
>> number of static pages (a hub, really) with links to other pages, such as
>> project-specific websites (e.g.>),
> Clearly, we have a hierarchy of the recommendations here:
> - common guidelines
> - library-specific guidelines based on/extending the common ones
> I'm talking about common guidelines here, not the library-specific ones.
>> or the wiki (> Unsubscribe & other changes:
> I suggest to not to maintain common guidelines on GitHub wiki or
> anywhere else - Wiki is volatile,
> too easy to edit by too many or too easy to sneak unwanted edits.

I think it's a judgment call, really:

I see your point, and I agree: on the one hand we have
version-controlled (relatively static) content, on the other we have
easy-to-change volatile content.

If it were for truly static content, I would wholeheartedly agree with
you. But a document describing how to deal with (compiler-specific)
warnings is inherently a moving target, and thus will quickly get stale
unless it's been actively maintained (read: updated regularly). And if
it's hard to change, people will just add their own guidelines elsewhere...


       ...ich hab' noch einen Koffer in Berlin...

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