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

On Wednesday 15 April 2015 15:32:12 Vladimir Prus wrote:

On 04/10/2015 05:28 PM, Andrey Semashev wrote:

...

On Friday 10 April 2015 09:19:48 Rene Rivera wrote:

...

On Fri, Apr 10, 2015 at 7:40 AM, Olaf van der Spek wrote:

...

Is it not possible to only allow merges from develop into master?

NO. Github doesn't have that kind of permissions control.

FWIW, I don't think limiting maintainers from accessing their libraries is the right way to go in the first place. One of the reasons why we moved to git was to decentralize Boost and allow more freedom to developers. What needs to be changed is the release process which currently relies on the global freeze instead of branching or forking.

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. 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.