Re: Fwd: [boost] [release] Is everyone ready for the 1.72.0 release (cycle)?

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2019-10-23 20:05:21

On Wed, 23 Oct 2019 at 21:44, Pranam Lashkari <plashkari628_at_[hidden]> wrote:
> On Mon, Oct 21, 2019 at 11:35 PM Mateusz Loskot <mateusz_at_[hidden]> wrote:
>
> > Miral, Olzhas, if you'd like to add anything to your work for this release,
> > please follow the dates included in the post by Marshal Clow.
> >
> > As far as I know, Miral would not be active for the next two weeks as she
> > is travelling. As far as her (or my part in it) project is concerned I have
> > a few comments to make.
>
>
>    1. There is one option in threshold_optimal_value "triangle" for threshold_optimal
>    which is still not implemented [1]. Which I promised to do and that's
>    why Miral did not implement this as part of her GSoC project. Such
>    an incomplete option can put users in confusion.

I have just removed it
https://github.com/boostorg/gil/commit/7ff2730f458ae1d7abb62554e1bf346d2f110a75

>    2. I was also planning to work on new convolve_2d functions to make the
>    APIs and implementation similar to convolve_1d this would change the
>    existing API[2]. This change will also allow users to use all types of
>    boundary options. So according to me, it is better to release the
>    function/API when it is completely done instead of changing after
>    one release.

I think we could move `convolve_2d` to boost::gil::detail namespace.
The convolve_2d can still be considered as an auxiliary function
serving the GSoC features.
Offering it sooner but as an implementation detail allows us to break it
in future while still allowing users (and ourselves) to use it sooner.

What do you think?

Stefan, what do you think?

> Earlier I thought these idea/project are not going to be part of these
> release as they were labelled "1.72+" and as a result, I was working really
> relaxed not keeping any deadlines in mind.

It is my fault - I got over-excited about it and planned for release.
I probably should keep milestone undecided completely.
In future, I'll try to be more considerate about that.
But, please don't take milestone assignments as a plan fixed in stone
that expects you will do something for specified release.
It is more of a proposal, a draft, that can certainly be objected.

> There is one more thing pending from my side which is discussed in #391
> [3]. I am not sure of commits related to it are going to be merged in
> master for this release or not. So not putting this on high priority.

I don't see any problems here.

Pranam, thank you very much for your insights.
The extra pair of eyes monitoring what we do in GIL is highly appreciated.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net