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 
>>> "We might also re-host this document somewhere on github/boostorg?"
>>>  https://lists.boost.org/Archives/boost/2018/07/242617.php
>>> 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 boost.org 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 boost.org.
>> Ideally, boost.org 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. http://boostorg.github.io/
> 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 (https://github.com/boostorg/boost/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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk