-Original Message-
From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
development-boun...@lists.berlios.de] On Behalf Of Zach Welch
Sent: woensdag 8 juli 2009 0:35
To: Øyvind Harboe
Cc: openocd-development@lists.berlios.de
Subject: Re: [Openocd-development] 0.2.0
If I may be very blunt: I don't think we are very close to a 0.2.0 release.
It seems (based on bug reports) the recent changes broke some of the
existing functionality. That needs to be tested fixed first. IMHO release
0.2.0 should have at least the same functionality that 0.1.0 had.
@lists.berlios.de
Subject: Re: [Openocd-development] 0.2.0 release... on hold?
On Wed, 2009-07-08 at 00:14 +0200, Øyvind Harboe wrote:
We need to find some balance. Right now, the presses are too heavily
biased toward development to the extent that release suffers badly.
I
On Mon, 2009-07-06 at 15:16 +0200, Øyvind Harboe wrote:
I've determined that single stepping is busted for
svn head arm926ejs using parport against wi-9c.cfg
(bisecting this now).
This does not meet my standard for explaining the changes that went
into the OpenOCD tree, in so far as I still
Hi Zach,
thanks for a good post followup on this.
I'll try to adjust to the new rules of engagement and stop committing
willy nilly.
W.r.t. when 0.2 should go out of the door, I'm thinking that we
should have a few days without finding and fixing regressions
before we say it's time to release.
On Tuesday 07 July 2009, Øyvind Harboe wrote:
My current feeling about 0.2 is that we should allow at least
a week of work on the outstanding reset problems before we cut
the release.
That seems reasonable. Likewise some of the issues turning
up with different JTAG adapters.
It's funny how
On Tue, Jul 7, 2009 at 11:02 PM, David Brownelldavi...@pacbell.net wrote:
On Tuesday 07 July 2009, Ųyvind Harboe wrote:
My current feeling about 0.2 is that we should allow at least
a week of work on the outstanding reset problems before we cut
the release.
That seems reasonable. Likewise
On Tue, 2009-07-07 at 14:02 -0700, David Brownell wrote:
On Tuesday 07 July 2009, Øyvind Harboe wrote:
My current feeling about 0.2 is that we should allow at least
a week of work on the outstanding reset problems before we cut
the release.
That seems reasonable. Likewise some of the
What about cutting the release and waiting a
week to see if something worthwhile appears that
makes you want to cut the release from a newer
svn version?
Allowing commits meanwhile, but encouraging postponements
of more crazy stuff + commits for collaboration purposes.
Cutting the release from
On Tue, 2009-07-07 at 23:46 +0200, Øyvind Harboe wrote:
On Tue, Jul 7, 2009 at 11:02 PM, David Brownelldavi...@pacbell.net wrote:
On Tuesday 07 July 2009, Ųyvind Harboe wrote:
[snip]
Create a release timeout counter which is reset upon
acknowledged regressions reported?
We might not release
We need to find some balance. Right now, the presses are too heavily
biased toward development to the extent that release suffers badly.
I definitely want to see a reset of the release timeout counter
when we discover such problems as we have seen in
the last week.
The step bug alone would
On Wed, 2009-07-08 at 00:14 +0200, Øyvind Harboe wrote:
We need to find some balance. Right now, the presses are too heavily
biased toward development to the extent that release suffers badly.
I definitely want to see a reset of the release timeout counter
when we discover such problems
However, there does need to be a limit to the number of resets
that we allow for new issues.
Agreed.
Though I believe that it is a hypothetical situation where
we discover major flaws every few days. *If* we did, then
we *should* hold off the release.
Have we discovered anything but the reset
Hi all,
With my latest series of commits, I believe that the release process is
finally ready to see action. That said, we have seen a bit of
bug-fixing activity during the time that I have been preparing, and
several new patches have hit the repository. The countdown is on hold.
The new
I've determined that single stepping is busted for
svn head arm926ejs using parport against wi-9c.cfg
(bisecting this now).
One concern that I have with 0.2 is that it contains a lot
of *great* refactoring work, but this is unobservable to
the casual user.
It will take a *long* time get testing
15 matches
Mail list logo
