Re: [boost] [optional] Changes in Boost.Optional

Subject: Re: [boost] [optional] Changes in Boost.Optional
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2014-09-01 22:04:05

On Tue Sep 02 2014 at 5:48:09 AM Edward Diener <eldiener_at_[hidden]>
wrote:

> On 9/1/2014 11:48 AM, Dean Michael Berris wrote:
> > On Tue Aug 26 2014 at 3:59:12 PM Dean Michael Berris <
> mikhailberis_at_[hidden]>
> > wrote:
> >
> >> On Tue Aug 26 2014 at 9:38:37 AM Eric Niebler <eniebler_at_[hidden]>
> wrote:
> >>
> >>> On 08/24/2014 11:20 AM, Rob Stewart wrote:
> >>>> [Corrected subject to target optional.]
> >>>>
> >>>> On August 24, 2014 7:55:11 AM EDT, Dean Michael Berris <
> >>> mikhailberis_at_[hidden]> wrote:
> >>>>> I realize that this message may have not passed the spam filters.
> >>>>>
> >>>>> Can someone comment on the changes in Boost.Optional in 1.56.0
> breaking
> >>>>> existing code?
> >>>
> >>> <snip>
> >>>
> >>> Hi Dean,
> >>>
> >>> I don't know the specifics, but if you file a bug, at least it won't
> get
> >>> lost.
> >>>
> >>>
> >> Filed: https://svn.boost.org/trac/boost/ticket/10399
> >>
> >> Thanks Eric.
> >>
> >
> > It's now been almost a week and there's been no update on the issue. I
> > think this is serious enough that I'm positive it couldn't just be me
> > that's experiencing this regression.
> >
> > Can someone with access to MSVC 2010 confirm whether this indeed is an
> > issue, and whether it's actually a regression?
> >
> > If I wanted to get a fix in for this, whom do I send the pull request to
> > (community maintenance team) so it gets fixed for 1.57?
>
> Just make a pull request against Boost Optional.

Which fork? Just direct to the boostorg repo?

> Whoever is a Boost
> Optional maintainer will get the pull request. It is not up to you to
> have to determine, when making a pull request, who should get the request.
>
>
It actually is, because I need to determine which maintainer is active,
which one has access to MSVC 2010, be iterating on the pull request with
that maintainer's fork, and then have that maintainer in their leisure
merge it into the boostorg repo. If the process is a free-for-all on the
boostorg repo, then I'm afraid I'm going to have to say that may not scale
well especially if there's more than one maintainer of the library.

So I ask again -- to which fork, what are the expected turn-around times
(who do I @mention in github) to get their attention?