On Tuesday 22 July 2014 08:15:35 Robert Ramey wrote:
Andrey Semashev-2 wrote
I agree that some degree of freedom is needed, and in fact I'm typically in favor of less restricting approaches. However, libraries in Blincubator are targeted for inclusion in Boost and therefore should respect requirements and preferences imposed by Boost. For example, I expect all libraries in Blincubator to be licensed under BSL.
boost "requirements and preferences" is quite a slippery concept. This is apparent when one looks at any review. These often bring up disagreements regarding documentation, code organization, naming, etc., etc. These will never really be agreed upon.
I think they are agreed upon, requirements at least. http://www.boost.org/development/requirements.html
The libraries should follow directory layout and symbol naming guidelines set by Boost. The choice of documentation format and build system is probably less strict but obviously QuickBook and Boost.Build should be the first candidates.
LOL - I don't think boost.build is a good tool for the build system for any library submitted to the incubator. I explicitly recommend an alternative. (whether its a good choice for boost itself - another long debate off topic here).
And I'm not a great fan of QuickBook either. That would be a longer discussion - but suffice it to say that I believe that the boost toolset currently holds boost back - and has been doing so for some time. Of course that's my opinion and it's another discussion. But I focused on making it
Although I'm quite happy with QuickBook, I won't debate on whether Boost is held back by its tools or not. It's irrelevant. What is relevant is that if a library realistically aims for inclusion into Boost, it will have to integrate with Boost.Build. For good or bad, we don't have an alternative now and I didn't see any signs of that changing in the near future. As for QuickBook, well, let's just say people are much more willing to rewrite old docs in QuickBook than keep maintaining the original.
The same goes for preference of not storing auto-generated files in the library repo.
If your not the one actually developing the library - why on earth to you care?
As a mere bystander I care because I have to download it. As a potential contributor or co-maintainer I might be much more affected.
You're only looking at the html documentation. What makes you think you can/should dictate how one does his development? If if you think you have that right/authority, how would you enforce it? Every submission to the incubator conflicts with someone's idea about how work should be done. If I imposed these kinds of rules - there might be an incubator - but there wouldn't be any submissions in it.
This manner of thinking is a big reason why boost has stagnated.
Wow. Look, I didn't claim any authority and I'm sure in no position to force anyone. I just stated that there are certain requirements and common preferences that a candidate library should meet. It is of course your right to ignore them in Blincubator, but to my mind this doesn't help the candidate libraries.