Boost logo

Boost :

Subject: Re: [boost] Support for BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
From: Stephen Kelly (steveire_at_[hidden])
Date: 2013-10-10 12:43:19


On 10/10/2013 03:47 PM, Sergey Cheban wrote:
> On 10.10.2013 17:08, Stephen Kelly wrote:
> >>>> I think it is reasonable to push them in several days after
> releasing
> >>>> 1.55 (providing there is no significant negative feedback).
> >>> That makes no sense at all. My patches affect the master branch,
> not the
> >>> release branch.
> >> The current gap between the trunk and release branches looks strange
> >> for me. I've read several times about changesets that were living on
> >> the trunk for a long time without being merged to the release. I think
> >> that this practice is bad and the changesets on the trunk should be
> >> merged to the release branch ASAP providing the tests are green.
> > This is so shocking that I'm certain I've misunderstood you.

Well, apparently I did not misunderstand you. :) Color me shocked.

What is the point of creating a release branch to stabilize, if you are
just going to merge trunk back into it later?

Especially for such very dubious reasoning as 'it looks strange to me'?

Define strange.

> May be I just don't understand the current boost workflow. But as I
> can see the current workflow leads to the problems like the following:

You're quoting things out of context instead of linking to gmane where
there would be context.

If you wish though, I can make guesses at what's going on.

> ========================================
> On 09.10.2013 3:12, Rich E wrote:
>
> > I'm seeing that Fusion has not been updated with fixes for #5010
> > <https://svn.boost.org/trac/boost/ticket/5010#comment:24> a /3/ /year
> > old(!)/ bug, that is reported as fixed. Why is this? From what I can
> > tell, changeset #4441
> <https://svn.boost.org/trac/boost/changeset/84441>
> > fixes the issues I ran into, but the 1.55beta package doesn't reflect
> > this...
> ========================================

What happened? Did someone commit the fix to trunk instead of release?
If so, then maybe they made a mistake. If it was a mistake, then
cherry-pick the commit. Done. No big deal. Mistakes happen.

> and following:
>
> ========================================
> On 03.08.2013 1:33, Gennadiy Rozental wrote:
> > Tim Blechmann <tim <at> klingt.org> writes:
> >> i've reported an issue before that boost.test in the release branch is
> >> pretty broken. *all* tests of the boost.heap testsuite segfault
> like this:
> >
> > There were no changes in boost release for several years.

It is my understanding that the release branch should contain the boost
1.5.5 beta. With that understanding in mind, I can't understand this
quoted sentence. What does it mean?

> Can you wor karound
> > it for now?
> >
> >> boost.test in trunk works fine, though ... i wonder, will it
> eventually
> >> be merged to release?
> >
> > I lost my work on new docs unfortunately to broken laptop, still
> trying to
> > revive it, but I'm lacking time to really get to it. Maybe this can
> give me
> > another reason to finally push it out.
> ========================================

Broken laptops are not related to trunk and release branches. I don't
know why you quoted this.

>
> and following:
> ========================================
> On 08.10.2013 12:50, Akira Takahashi wrote:
> > 2013/10/8 Domagoj Saric <dsaritz_at_[hidden] <mailto:dsaritz_at_[hidden]>>
> ...
> > With MSVC12 RC:
> > * 1.54 and 1.55 b1 RC - lots of:
> > ..\boost/iterator/detail/__facade_iterator_category.hpp(__166) :
> error
> > C2039: 'assert_not_arg' : is not a member of 'boost::mpl'
> >
> >
> > This issue fixed by this commit.
> > http://lists.boost.org/boost-commit/2013/05/46330.php
> >
> > However, not merge to release branch yet.
> ========================================

What's the problem? If someone writes that it is not merged *yet*, then
they intend to apply it to the release branch somehow, right?

Is merging trunk into release part of the boost release strategy?

Thanks,

Steve.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk