On Wed, Apr 15, 2015 at 8:24 AM, Jürgen Hunold
Hi Andrey,
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
Am Mittwoch, 15. April 2015, 15:52:13 schrieb Andrey Semashev: 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