Re: [boost] [lib maintainers]Pleaseidentifyheadersinboost-root/boost

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-11-19 01:54:22

Joel de Guzman wrote:

>>>>> No, of course not. But was has boost/shared_ptr got to do with
>>>>> this?
>>>> wow - this is the iconic example of a violation of "standard
>>>> practice"
>>> Why are you saying that while insisting that there's no "standard
>>> practice"?
>>
>> There is none - that's why I put it in quotes.  "standard practice"
>> is a fluid definition in this context.  The latest version cited now
>> seems to depend on something referred to as "core libraries"
>> whatever that means.
>
> We can't argue that way. Give me your definition of "standard
> practice" first. Seems I'm looking at Mars and you might be
> looking at Jupiter.

I'm not the one claiming there there exists an unambiguous
definition of "standard practice" in this context so that's why
I haven't claimed I followed it.  My claim is that its undefined
and being stretched and distorted to fit with every post on
this thread.  I don't know what it is.  I don't know where its
defined.  That's why I had to try to extract from the example
of the way boost was organized at the time.  Given that is the
way I had to do it, its no wonder at least some people
think I got it wrong.  Given the lack of definition - its inevitable
that there is going to be disagreement on some decision which
is supposedly based upon it.

And BTW - boost is riddled with this problem.  The same
sorts of issues plague documentation standards, usage of
boost/detail, release and testing procedures.

> So, I'm curious. Is there a precedent that prompted you to
> place static_warning in the root boost directory and in
> namespace boost?

I just followed the example of static_assert.hpp.  I was
new to boost so I wasn't aware of any precedent. I
followed what seemed to me to be an inescapably
obvious pattern.

Also the WHOLE serialization library was subject to
review.  Everything was open to question. The first
review produced a rejection and a very long list
of things that were unacceptable.  The next version
addressed all the issues raised and the library
was accepted with very little change.  It was my
understanding that the review was to cover all
aspects of the library.  I could just as well argue
that those components were reviewed.  I'm
not going to do that however. The serialization library
is a large library and really needed some things
that boost didn't have like strongtypedef,
extended_typeinfo, static_warning, and a couple
of others I forgot.  They really arn't part of the
library - just things boost was missing.  So I put
them where other similar components were found
and no one objected neither then nor for years
afterwards.  And these things weren't hidden.  They
were prominantly featured in the documentation
as separate components with links to the true
path.

> It's not perfect, for sure. Discussions like this, hopefully,
> should get the issues straightened. Again, I'm curious, it
> seems (you say) that you based your judgement from discerning
> standard practice from existing libraries. So which is it that
> you based placing static_warning in the root boost directory and
> in namespace boost on? Please understand that I want to look at this
> constructively and objectively.

I appreciate that.  See above.  Also consider the context.
Source code, headers, test programs and documentation of
the serialization library I believe is on the order of 30,000
lines of text.  (we'll exclude the email discussions, reviews etc.)
A header like static_warning is maybe 100 lines.
I saw a very close analogy, leveraged on it, and moved on.
Without clearer more explicity policy, one doesn't have
much other alternative.  Actually, considering the scale
of what was involved, the possible misplacement of a
small number of headers (8?) is very small potatoes and
has been blown way out of proportion.  And considering
boost's other problems, release procedures, documentation build,
out of date documentation standards, components used but not
formally tested, testing on just a subset of build combinations,
bjam, etc.  It's microscopic potatoes.

>> So for me, its not a question so much of this or that directory
>> structure but the whole idea that its ok to change the rules in
>> the middle of the game.  It wastes huge amounts of time.
>
> I disagree. IMO, no-one is changing the rules in the middle of the
> game. It's just that you did something that slipped the radar
> screen.

LOL - we could disagree on this, but as a practical matter the
effect is the same.

>Our task now is to make sure that this does not happen.
> And, I agree with you that we should have some kind of policy
> written.

Halleluhuh

How about this as a policy:

a) No new headers in boost/... Boost is too big for this
b) small libraries can be placed in boost/utility and ancillary
files such as tests, source code, documentation, etc be placed
in the same spots they are as other libraries
c) No concept of "core libraries" vs "non-core" libraries
d) exception to a) one convenience header per library
e) documentation in boost/libs/utility/doc/... same as other libraries
f) library authors encourged to move components over time
out of boost.  This would include ALL the ones I posted
before (except for those which are convenience headers).

>> Hmmm - well, maybe we'll just submit static_warning.hpp for a fast
>> track review and be done with it.

I haven't done this up until now for a couple of reasons.  I thought
it mostly redundant.  It takes a lot of time on my part.  It would
take time from other things I thought were alot more urgent and
important.

these would be state_saver.hpp, static_warning.hpp, strongtypedef.hpp.
The other ones of mine are pfto.hpp, smart_cast.hpp, and I would
be inclined to migrate them out at a convenient time in the future.  So
you would only have about 100 others to deal with.

Robert Ramey

>
> Cool!
>
> Regards,