From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2019-10-23 20:41:45
On Wed, 23 Oct 2019 at 22:22, Stefan Seefeld <stefan_at_[hidden]> wrote:
> On 2019-10-23 4:13 p.m., Mateusz Loskot wrote:
> > I think the GitHub milestones situation needs to be clarified now.
> > Currently, there are two milestones:
> > - "Boost 1.72" (3 items)
> > - "Boost 1.72+" (57 items)
> > I had not expected to release the GSoC work with 1.72,
> > so all the GSoC PRs are assigned to "Boost 1.72+".
> > Since we have decided to make the release, then we will
> > release all the work that is assigned to both milestones.
> > It means, the two milestones should be merged into one "Boost 1.72".
> > It also means that (subjects of) the PRs of the combined "Boost 1.72"
> > milestone can make it into GIL release notes for the Boost 1.72 release.
> > Does it make sense, do we agree? Stefan?
> I'm still a bit confused about the current situation: it seems there are
> a few unfinished bits and pieces, which we don't expect to be able to
> wrap up in time for the upcoming release.
Those unfinished pieces are ideas and plans that during GSoC
were decided as non-critical for completing GSoC. So, related issues
were opened and notes taken on what is idea/plan.
Shortly, there is no timeline or expectation when those will be completed.
> (Note that the 30th of October
> is the deadline for *major* changes only. So if we merge all we have
> now, we should still have time for minor fixes and improvements after that.
Correct. I keep the 30th as an early reminding whip :-)
> But no pressure, I can't judge how much work is missing to wrap
> everything up, and how much risk these changes would cause.)
Luckily, according to Boost policies can break things from Boost
release to release :)
> I still think that we should release what we have as early as possible.
> And given that what we are talking about are new APIs, not changes to
> existing APIs, I doubt it will be a big problem if we apply minor
> changes to those APIs in the next release. It will take time for new
> users to adopt the new APIs anyhow, and if we mark the API in our docs
> as "experimental" as well as "subject to change", I think that would be
> entirely acceptable.
Yes, but there is one small exception to that: boost::gil::convolve_2d function
which we already know (see Pranam's
that it will change during implementation of the plans/ideas I mentioned earlier
(and Pranam mentioned in his post).
So, I suggested to release this function in 1.72 as
I believe it would be acceptable to hide now and publicise in future.
Question: do you agree with this hiding?
> In other words, my current thinking is: let's merge what we have even if
> it's not entirely stable or complete. Then let's focus on documentation,
> making sure the relevant pieces are documented as "experimental"
> Does that make sense ?
Yes. I agree with your approach.
-- Mateusz Loskot, http://mateusz.loskot.net
Boost list run by Boost-Gil-Owners