[GIL] Bringing old bug fixes on development branch into regular boost releases

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[GIL] Bringing old bug fixes on development branch into regular boost releases

Marcel Metz
Hello boost devs,

I'm a user of the Boost.GIL library and maintained a fork inside inside
another project because GIL lacked some features at that time this
project needs. This GIL fork happened with boost release 1.37.  After
reviewing the changes recently it turned out that those can be
implemented without maintaining a dedicated GIL fork.

However when building the project with the upstream GIL library
some compiler specific build bugs popped up.  It seems like the forked
GIL version already had fixes for those whereas the upstream Boost.GIL
doesn't.  Further investigation showed that some of those were fixed
years ago in the GIL development branch, but never made it back into
the master branch (and as far as I understand master is used for
release tags).

All of those were reported:
#3908 - using boost::gil fails when upgrading to libpng-1.4.0
#7270 - C++11 narrowing problem in gil
#8896 - image_view compile error under clang 3.1
#9517 - boost gil compile error because of type narrowing (dup of #7270)

Is it possible for the maintainer to cherry-pick the corresponding
commits from development onto master and put them into the next boost
release or are there other steps involved that prevent the bug fix
inclusion?

Regards

Marcel

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [GIL] Bringing old bug fixes on development branch into regular boost releases

Robert Ramey
On 2/6/17 5:15 AM, Marcel Metz wrote:

> Hello boost devs,
>
> I'm a user of the Boost.GIL library and maintained a fork inside inside
> another project because GIL lacked some features at that time this
> project needs. This GIL fork happened with boost release 1.37.  After
> reviewing the changes recently it turned out that those can be
> implemented without maintaining a dedicated GIL fork.
>
> However when building the project with the upstream GIL library
> some compiler specific build bugs popped up.  It seems like the forked
> GIL version already had fixes for those whereas the upstream Boost.GIL
> doesn't.  Further investigation showed that some of those were fixed
> years ago in the GIL development branch, but never made it back into
> the master branch (and as far as I understand master is used for
> release tags).
>
> All of those were reported:
> #3908 - using boost::gil fails when upgrading to libpng-1.4.0
> #7270 - C++11 narrowing problem in gil
> #8896 - image_view compile error under clang 3.1
> #9517 - boost gil compile error because of type narrowing (dup of #7270)
>
> Is it possible for the maintainer to cherry-pick the corresponding
> commits from development onto master and put them into the next boost
> release or are there other steps involved that prevent the bug fix
> inclusion?
>
> Regards
>
> Marcel

This raises the question of who is maintaining the library - if anyone.
I doesn't seem that anyone is.  Perhaps since, you're doing the work in
any case, you'd like to take it on. Checkout out the Boost Library
Official Maintainer program.

Robert Ramey



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