Re: [boost] The Release Manager's Point of View

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-06-06 14:05:50

"Thomas Witt" <witt_at_[hidden]> wrote in message 
news:f46pqe$e0f$1_at_sea.gmane.org...
>
> Hi,
>
> David Abrahams wrote:
>> on Mon Jun 04 2007, "Gennadiy Rozental" 
>> <gennadiy.rozental-AT-thomson.com> wrote:
>>
>>>> As an example on how bad things are: I would like to merge changes for
>>>> 1.34.1 one at a time so that I can identify the change that broke
>>>> something. With the current turn-around time, even when the system 
>>>> works
>>>> as designed, this is impossible unless we aim for a X-mas release date.
>>> IMO, this is not a responsibility of release manger *whatsoever*. 
>>> Release
>>> manager have to release only the staff that is already tested. No 
>>> testing,
>>> no merging. If I want my changes to be released I will invest time into
>>> making sure they passed all the tests.
>
> This argument is bogus. Eventually somebody has to decide what goes in and 
> what does not.
> Whether it's going in a release ready branch or a release does not matter. 
> Both need
> oversight and to some degree coordination.

No coordination is required. At least no coordination with release manager. 
Two developer may need to coordinate their efforts to release new versions 
of their libs. I am about to post my proposal. You should see it there.

> That function has to be centralized it can't be done by single developers.

Why?

> Whether we call that person release manager or not is of little
> importance to me.
>
> In case of a point release it has to be the release manager that 
> coordinates patches.

I strongly disagree. Release manager doesn't need to know anything about 
patches at all. We night just have different views on what are the boost 
release procedure is (or should be).

>> I agree that testing and merging should be taken off the table as
>> concerns for the release manager.
>
> Let me add a little detail here. It's not the testing and merging as such 
> that is a big
> burden. Currently merging works pretty well for me. I control the workload 
> by simply
> asking people to apply *approved* patches for me. I think for a point 
> release the release
> manager always needs control over what is merged. This part of the job 
> can't be taken off
> the table.

It can be and it should be. Release can't wait for me to commit/merge even 
single byte.

> The problem with testing is not monitoring test results. The problem is 
> managing the
> testing itself. I.e. making sure tests run as needed, making sure only the 
> "right" people
> submit release tests, debugging bogus results, monitoring the reporting, 
> in case of a
> genuine regression tracking it to a specific change. These things need to 
> be taken off the
> table. Most of this can be achieved by fixing the regression test system.

IMO this is orthogonal to the boost release procedures (or it should be)

Gennadiy