This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: DELAYED: GDB 6.7 branch creation scheduled June 25th

> These facts suggest to me that it's best to delay the branch, possibly by a
> month or two, not backdate it.

As far as I am concerned, the fact that we use backdating is unrelated
to where we decide the branchpoint to be. I like backdating, because
it allows me to put the head in maintenance mode for a couple of days
while I work on the branch.

> I guess I'm used to Emacs where the freeze alone lasted for three
> years (which _is_ ridiculous) but where does the pressure come from
> for such a prompt release?

There is no hard pressure; actually, no pressure at all, as far as
I am concerned. But having a rough schedule helps us have structure.
The sense of promptness is relative. I personally like releasing often.
In my sense, GDB has enough material to be released twice a year, others
mentioned that they would like more frequent releases. In any case, if
it turns out that at one point we feel that we haven't done enough when
comes the time to start preparing the next planned release, then for
sure we'll just delay it. But what I do NOT want to do, is to delay the
branch because we're waiting for the next fix, enhancement, etc, unless
there is a compeling reason to.

In this particular case, I think we have more than enough material
to start a new release. Just to verify my impression, I had a look
at the NEWS file, and the "since 6.6" section is actually very long!
And the great thing is that I know more are coming for the release
following that one (which I hope we'll be able to call it GDB 7 :-).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]