Re: [boost] Fwd: Boost.Python build error in 1.58 RC1, 2 and 3 (OK in Beta 1)

Subject: Re: [boost] Fwd: Boost.Python build error in 1.58 RC1, 2 and 3 (OK in Beta 1)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-04-15 10:51:45

On Wednesday 15 April 2015 15:24:53 Jürgen Hunold wrote:
> Hi Andrey,
> 
> Am Mittwoch, 15. April 2015, 15:52:13 schrieb Andrey Semashev:
> > On Wednesday 15 April 2015 15:32:12 Vladimir Prus wrote:
> > > I don't think there's a primarily technical problem. No matter how
> > > release
> > > process goes, we either need to assume that 'master' branch of any
> > > component is good to be released at all times, or coordinate with
> > > maintainers of 120 components to determine which revision of 'master' is
> > > really good to be released.
> > > 
> > > You can guess which approach release managers would prefer.
> > 
> > I'm not arguing against taking master as a starting point for a release;
> > it's a reasonable compromise. What I'm saying is that once release process
> > has started there should be no restriction on updating master in
> > submodules
> > (i.e. the freeze), the release should branch off the main code base and
> > get
> > finished regardless of the modifications developers make. It is possible
> > that master is broken at the point of branching - and part of release
> > process is to fix it for the release or revert to a last known good
> > version. But the probability of breakage is greatly reduced with this
> > approach.
> 
> The main problem is the necessary regression testing needed to actually
> verify that the regressions
> a) are indeed fixed
> b) don't introduce new failures.
> 
> And our current testing system is hardcoded to "master" and "develop"
> branches. And can't test anything else, as it relies on the test runners
> admins to set up which branch to test.

Well, we could switch the master branch testing to release testing for the 
time while release is being prepared. This could probably be done with a 
commit to the testing scripts in master?