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

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-11-19 19:26:09

Robert Ramey wrote:
> Joel de Guzman wrote:
>> Robert Ramey wrote:
> 
>> You mention below that you based that action by following
>> static_assert.hpp. You see now why it is wrong? There's
>> a big difference -- static_assert was reviewed. Yours
>> is not. To be considered a boost library, it must be
>> reviewed independently outside of serialization.
> 
> So its not the placement itself that's wrong? 

I think so, yes. static_warning can very well be a "core"
library like static_assert IFF it has undergone a boost
review and is accepted.

> The error is
> is only that it reviewed as part of something else rather than
> independently?  

Yes. That's the crucial misinterpretation of the process and the
(unwritten) standard practice. The libraries I authored, for
instance, has tremendous amount of support code that ideally
could exist outside the framework as stand alone components.
These parts have undergone the same review process as serialization
components did. If I, or all libraries that has been accepted thus
far, were to place them outside the sphere of their host into
root, imagine the result.

> So the correctness of the placement of
> such a module is defined in terms of the outcome of a
> formal review?  

Correctness of a lot of things depend *not only* on the formal
review. We can never have a perfect system.

> Does that seem like a practical system
> to you?  

Well, unless you have a better suggestion, the current review
process works. It's up to us to uncover the glitches and propose
remedies and workarounds or, if you will, better processes.

> Suppose static_warning.hpp were reviewed
> and for some reason it was rejected and it were moved
> into the serialization library.  Then we would have the
> situation where two very similar libraries would be in
> two entirely different places.  Would this be logical from
> the standpoint of someone examining boost and trying to
> understand where stuff is?  

No. And that is unfortunate.

> Should review results be
> included as permanent part of every library?

Not sure about that. At least an immediately accessible record of
all the reviews would be helpful, I think.

> Note
> that these are rhetorical questions meant to illustrate
> my view that defining the "expected placement" or
> "standard whatever" which depends upon the result
> of a formal review (especially when examination of
> such a review) has some problems.  What is better
> is a stated policy and a review acceptance process
> which enforces conformance to such a policy.  Perhaps
> had such a policy existed at the time and the formal
> review process stated that comformance to such a policy
> was one of the things to be checked, this particular
> instance might be been addressed at an opportune time.

Agreed. Still, even after we settle this issue for now,
there will still be things that we will not catch and
even more things that will be uncovered in the future
that we've missed yet may be detrimental to the health of
boost in the future to come. There's no silver bullet.
We can only try to do our best, as we always have. What's
equally important is that we remain agile to future changes
and accept that we do make mistakes, we do uncover unforeseen
bugs. And it is part of the ongoing process to correct them
when we find them.

> I previously posted the following list.  I'm not sure which
> ones are convenience headers and which are not.  But
> somehow I don't think they've all been independently reviewed.
> given that there in the boost directory I don't know where
> to look for the documentation without out doing some
> sort of search.  (Hmmm - now I'm curious what something
> like "none.hpp" does. ahhh - its parto of optional.hpp.)
> 
[snip list]

Once we settle this, we can run through the list and inform
the author of the violation, if there is one. I notice though
that most of the items in your list have been reviewed. Can
you please trim your list to only those like static_warning?
none.hpp is probably one of them, AFAIK.
> 
>> Resistance to change
>> something that is broken does not help. You do agree that
>> free for all pollution of the root directory and namespace
>> is not good, right?
> 
> I do - I was just trying to follow established patterns.  But
> now you raise the real issue.  Given the size that boost
> has grown to and the problems that this has engendered
> I don't think that there should be anything in the boost
> directory/namespace other than convenience headers.
> (personally I don't even like convenience headers but
> I'm think I'm in the minory on this point.)

In my mind, that would be ideal, yes. But I'm not sure it's
practical as this would cause massive breaking for existing
libraries.

> lots of people did and there is.

I don't think it's chaos at this point. There's still chance to
correct the trend.

I'll reply to the rest of your post in a new thread later.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net