RFC: gdb-7.12 timeframe?

RFC: gdb-7.12 timeframe?

[Joel Brobecker]

Hello,

It's been almost 6 months since we started our previous release
cycle, so now is a good time to consider whether or not we feel
we have enough goodies to start a new process.

We have two questions to answer:

  1. When to start the process (ie stabilize master and create
     the release branch);

  2. What timeframe to shoot for in terms of the 7.12 release.

The part that worries me is that we're about to enter the month
of Aug, which is traditionally a very slow month due to summer
holidays.

What I would like to propose is we try to create the branch soon.
This means we make a call for blocking issues before the branch
is created, and create the branch, say, one week from now.
Issue a first pre-release then.

Meanwhile, we can try fixing all reported issues that were found
and deemed blocking for the release. To avoid having some issues
being reported too late, I propose we wait for September to make
our the 7.12 release. If necessary, we can make a second pre-release
early september.

Thoughts?

-- 
Joel

Re: RFC: gdb-7.12 timeframe?

[Yao Qi]

On Wed, Jul 20, 2016 at 6:24 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> Hello,
>
> It's been almost 6 months since we started our previous release
> cycle, so now is a good time to consider whether or not we feel
> we have enough goodies to start a new process.
>
> We have two questions to answer:
>
>   1. When to start the process (ie stabilize master and create
>      the release branch);
>
>   2. What timeframe to shoot for in terms of the 7.12 release.
>
> The part that worries me is that we're about to enter the month
> of Aug, which is traditionally a very slow month due to summer
> holidays.
>
> What I would like to propose is we try to create the branch soon.
> This means we make a call for blocking issues before the branch
> is created, and create the branch, say, one week from now.
> Issue a first pre-release then.

We need collect issues first, and decide whether one week is enough to
stabilize the master and create branch then.  I didn't follow the regression
tests in buildbot, but I'll take a look.

Do we have a wiki page to track all these issues for release?

>
> Meanwhile, we can try fixing all reported issues that were found
> and deemed blocking for the release. To avoid having some issues
> being reported too late, I propose we wait for September to make
> our the 7.12 release. If necessary, we can make a second pre-release
> early september.

I have a travel at the end of the Sep, but I think 7.12 is already
released then.
The time is good to me.

-- 
Yao (齐尧)

Re: RFC: gdb-7.12 timeframe?

[Pedro Alves]

On 07/21/2016 11:32 AM, Yao Qi wrote:

> We need collect issues first, and decide whether one week is enough to
> stabilize the master and create branch then.  I didn't follow the regression
> tests in buildbot, but I'll take a look.
> 
> Do we have a wiki page to track all these issues for release?

Joel created:

 https://sourceware.org/gdb/wiki/GDB_7.12_Release

I've now added "7.12" as version and milestone in bugzilla, and
reassigned already-fixed bugs to the "7.12" milestone.

Open bugs that people think should be fixed before the release
should get the target milestone set to 7.12, so they can be easily
found by following the search url in that wiki page.

Thanks,
Pedro Alves

Re: RFC: gdb-7.12 timeframe?

[Joel Brobecker]

> > What I would like to propose is we try to create the branch soon.
> > This means we make a call for blocking issues before the branch
> > is created, and create the branch, say, one week from now.
> > Issue a first pre-release then.
> 
> We need collect issues first, and decide whether one week is enough to
> stabilize the master and create branch then.  I didn't follow the
> regression tests in buildbot, but I'll take a look.

Thanks for taking a look at the buildbot results.

Regarding stabilization, there are two approaches. We can stabilize
master to the point of near-release-readiness, which means we start
holding patches that may be unsafe (a little bit like GCC does).
Or we branch, and then decide which fixes we want for the branch.
I was proposing the latter, which is a little more work for the
branch, but allows development to continue on master. However,
I am happy with either approach. We've used the former in the past,
but given that we're entering the summer holiday period, it might
take a while before we hear from some of us about issues that,
under the stabilize-before-branch policy, we might want to fix
before we branch.

-- 
Joel