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: Rene Rivera (grafikrobot_at_[hidden])
Date: 2015-04-15 09:42:40

On Wed, Apr 15, 2015 at 8:24 AM, Jürgen Hunold <jhunold_at_gmx.eu> 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.
>

I wouldn't call it hardcoded.. But yes it relies on testers signifying the
branch to test. And yes it could be more flexible.

> Note that when I say "branch" above I don't necessarily mean "git branch".
> > In fact, it may be more convenient to use forks to isolate the code to be
> > released from the main code base and use pull requests for patches that
> > need to get into the release.
>
> As soon as we get an up-to-date regression testing and reporting system, we
> can use any branching scheme you can imagine. And a lot more probably.
>

Not sure what you mean by "up-to-date". Could you be more specific? And I
don't accept "use -insert-name- tool" as an answer. I want to know
structure and process answers (as tools are just tools).

That would mean using either Jenkins or BuildBot as a centralized server and
> some dashboard reporting tool for visualisation.
>

No it doesn't mean that. Although Jenkins or BuildBot (or a variety of
other testing resource management) system could be used in a solution. But
I'm not aware of *any* current reporting system that meets Boost needs. I
do spend a minuscule amount of time writing such a system.

> But I don't know anyone with enough spare time to set up such a system
> without
> being paid and working full time. Not to mention the hardware necessary for
> this...
>

But as you just said.. I volunteer my unpaid free time to maintain and
improve the testing infrastructure.

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail