Re: Merging GitHub milestones Boost 1.72 and 1.72+

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.

+1

> 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
https://lists.boost.org/boost-gil/2019/10/0315.php)
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
boost::gil::detail::convolve_2d,
see https://lists.boost.org/boost-gil/2019/10/0316.php
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"
> appropriately.
>
> Does that make sense ?

Yes. I agree with your approach.

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