On Thursday 17 April 2008 17:12, Brandon Sneed wrote:
> On Apr 17, 2008, at 7:30 AM, Lothar May wrote:
> > Brandon Sneed wrote:
> >> I can see with a compiler where you're shipping code to a customer
> >> this might be an issue, but with a debugger it seems more like
> >> self- inflicted pain.
> > I'm sorry but I disagree. You are saying that the stable release of
> > gdb should not be used because it contains bugs which have been
> > successfully fixed. What's the point in naming the new
> > releases "release candidates" then, when they have been candidates
> > over years?
They are offered as such, so that you guys -- the users -- can test
them, and report back to us that you are happy with them, and that
*you* believe they are ready to be marked as full releases; until you
start doing that, they will remain as "release candidates" until time
> Its ok to disagree, don't be sorry! The naming is more of an Earnie/
> Keith call than mine, though I do think it is appropriate at this
> stage. My tech preview builds started in Jan, so years isn't really
> applicable, and the previous 6.x releases were pretty buggy. At any
> rate, a debugger, however unstable doesn't impact customers you're
> shipping code to like an unstable compiler might, so I still stand by
> my comment. However, if its an issue for you, I urge you to stick
> with the latest official release.
I debug most of my code on Linux, so don't use the Win32 builds of gdb
much; thus I don't personally have enough good experience of how good,
or how bad any of those releases may be. I rely on reports from you --
the users -- to guide me in my decision as to when to promote any
package from "tech preview" to "release candidate" to "full release".
> > I'd say that, if the mingw "release process" continues as it is, in
> > a few years there'll be nothing but technology previews, and users
> > will have to find out for themselves which ones are the "most
> > stable". Of course I'm aware of the fact that you are doing this in
> > your free time, but I still think that this is something which could
> > be improved. I might be wrong though, feel free to correct me.
Sure it can be improved; *you* can help to improve it, simply by
testing, and providing the necessary feed back. Until *you* tell us
that a release candidate is an improvement over the last stable
release, then the status quo will simply prevail.
> That may be the case, but you must understand that OSS projects don't
> follow the corporate definitions of much of anything. Release vs.
> Release Candidate, Tech Preview, etc doesn't matter nearly as much as
> what works for you. All 'Release' really means here is that its been
> tested extensively, and the only way MinGW can get tested extensively
> is by users. Given the current userbase (which seems to be growing
> considerably as of late) and this style of time-tested-QA validation,
> it will always take a long time for something to move into Release
> We could always draw a line in the sand and say "this is release
> quality" but that would be disingenuous to users and imply some
> extensive validation cycle had been performed. So while I would
> like this to improve as well, I don't see it happening in the near
> term. We're doing very well overall as a project I think, but by
> depending on users for validation and other OSS projects for much of
> our codebase/improvements, our hands are tied.
Here, Brandon has pretty much said it all.