Hi Jeffrey, my motivation is to have all extension in one place where it would be easy for people to find extensions and also easy to add new extensions. Extensions can very small code pieces and reviewing them might only take a few hours. Ideally we should be able to just add extensions into boost. But reality shows us that's no an easy process. For instance, my extension is sitting in th review loop for months now with no end in sight. Having our own project might accelerate things and hopefully will create momentum for new extensions. We basically would copy and paste boost without having to deal with boost's overhead. Regards, Christian On Sun, Dec 6, 2009 at 6:46 PM, Jeffrey Hellrung <jhellrung@ucla.edu> wrote:

Christian Henning wrote:

...

Hi there,

to get the boost extension movement going how would people feel if we create a new project on sourceforge called "boost_extension". This will be a placeholder for all extensions to all boost accepted libraries. The goal is to have a project structure very similar to boost. For instance, all extensions have to have tests, documentation, etc supported by bjam. The folder structure will be the same boost, like

boost_extension\boost\gil\io or boost_extension\libs\gil\io\test\

There will be a review process as well. Only accepted libraries will be added. Hopefully enough people will be interested in participating.

As, for releasing, again we would model after boost. There will be a developing trunk and a release branch. Hopefully within the next couple of releases we can sync releases with boost.

I know there is a plethora of issues involving such an effort. Please let me know what you think.

Thanks, Christian

Can you explain to us (well, maybe just myself) what the motivation for this is?  Why should a boost_extension library not just be included in boost itself?  I guess I can think of a few reasons (e.g., "keep boost more focused on core libraries", "give a home to libraries wrongfully rejected from boost"), but I don't know if these are the reasons you have in mind; and whether they are or not, why those reasons justify the existence of a boost_extension project.

- Jeff

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi Phil,

If the problem is that the Boost review process is broken, let's try to fix that, not bypass it.  If the process is broken, we should fix it for all types of contribution - small or large, extension or new library.

Don't know about broken. Boost just accepted two more libraries in the past two months, or so. My problem is that I cannot find a review manager. boost::gil's maintainer, incl. me, are not available.

I am looking forward to the eventual review of your GIL IO extension and its inclusion in Boost.  Having had a quick look at the code some time ago, I think it would benefit from a full review, not some sort of "fast path".

I agree, I have received great help by some individuals, but at the end of the day I have to rely on my own resources. Trust, that's not the best way. ;-) Christian

Hi Christian, A late reply on this:

...

If the problem is that the Boost review process is broken, let's try to fix that, not bypass it. If the process is broken, we should fix it for all types of contribution - small or large, extension or new library.

Don't know about broken. Boost just accepted two more libraries in the past two months, or so. My problem is that I cannot find a review manager. boost::gil's maintainer, incl. me, are not available.

and this:

Adding new code to accepted libraries would mean going through boost's review process.

...

Not if the extensions are accepted by the library's maintainer.

Mhmm, I'm trying with Lubomir to keep gil up to date. Does that mean, I could add my new gil::io to gil without a review?

My preference is still a review, though.

Indeed, often a review is what is prefered. For Boost.Geometry (GGL) extensions we proposed the fast track review process (http://www.boost.org/community/reviews.html#Fast-Track). This fast track process is less "heavy" than the normal process, and there is (AFAIU) no Review Manager involved (the Review Wizard is involved though). I don't know how often fast track reviews are done, but to us it seems well suited for library extensions. Regards, Barend

Hi Andrey,

While I fully recognize the problem of new libraries acception into Boost (I'm in the same boat as you) I don't quite understand how the proposed boost_extension would be different from Boost itself. I mean, on what basis can we claim that boost_extension reviews will be more active and frequent than what we have in Boost? Consider also that Boost is a well recognized library with a wide community already, while boost_extension will be a new beginning.

There is no guarantee. But, people like me are being hold back. When gil was introduced there were a lot of people actively creating extensions. Having boost_extension might hopefully create some momentum. As, for instance, for boost::ggl there is still some momentum that could be harvest. We could even consider relaxing the rule of who can be a review manager. For me personally I would consider an active person with domain knowledge to be sufficient. Remember, extension can be very small.

Another point of concern for me is the release cycle of boost_extension. You mentioned earlier that this project is intended to be hosted on SourceForge. If I'm not mistaken, this means that we will have to set up a testing facility independently from Boost. This will also require quite an amount of additional arrangements to be done, such as a web interface with testing results, release scripts, etc.

I was hoping the people at boost could help out for the regression testing. It should be in their interest.

IMHO, such a project has a better chance to start if it uses current Boost facilities, at least at first. Perhaps, restructuring sandbox and periodical testing and releasing it as a separate package might be a good start.

Sure, the more help the better. Thanks for your insight, Christian

Hi Barend,

I do agree about a well-described structure for extensions. However, I'm not sure about all of this proposal. This completely separates the extensions from the libraries, even in releases. Indeed this will cost a lot of efforts in organization and maintanance.

Why not keep it like it is currently in GIL and in GGL (Boost.Geometry)? So instead of boost_extension at the root level, have it in .../boost/LIB/extensions and .../libs/LIB/test/extensions and .../libs/LIB/example/extensions (and probably the same for doc)? This way the (reviewed) extensions can be distributed within Boost and are automatically available for everybody. Besides that, the extensions are then kept together with the library they extend, which I would prefer.

Adding new code to accepted libraries would mean going through boost's review process.

The non reviewed extensions, and extensions-in-preparation, should live elsewhere, e.g. in the Sandbox, or maybe indeed at a specific Extension.Sandbox tree, or at an external resource (as GIL currently has)? Actually this is then like any Boost library in preparation.

Right now, I'm collecting gil extensions and trying to keep them alive but it's pretty unorganized.

Regards, Barend

Christian

Hi David, On Mon, Dec 7, 2009 at 12:34 PM, David Abrahams <dave@boostpro.com> wrote:

On Dec 7, 2009, at 8:55 AM, Christian Henning wrote:

...

Adding new code to accepted libraries would mean going through boost's review process.

Not if the extensions are accepted by the library's maintainer.

Mhmm, I'm trying with Lubomir to keep gil up to date. Does that mean, I could add my new gil::io to gil without a review? My preference is still a review, though. Thanks, Christian