Re: [Mingw-users] gdb not installed?

[Keith M. <kei...@us...>]

Hmm.  For some reason, this took several days to get from SF to my 
incoming POP3 mailbox, at my ISP :-(

On Thursday 21 August 2008 13:19:31 Earnie Boyd wrote:
> Quoting JonY <10...@gm...>:
> > Andy Schweitzer wrote:
> >> I just installed MinGW-5.1.4.exe but it has no gdb. Is this a
> >> bug? Do I need to do some other install step?
> >
> > Hi,
> > its on the sf release page.
> > <http://sourceforge.net/project/showfiles.php?group_id=2435&packa
> >ge_id=20507>
>
> Keith, I'm being lazy and asking rather than looking but do you
> have a document that outlines the terms we use on the FRS?

None at present.  I still have a TODO item, to prepare a document 
outlining conventions for naming of released packages; when I find a 
round tuit for that, I guess it should also specify the release 
category names used in the FRS.

> The link JonY provided has releases of "Release Candidate",
> "Technology Preview" and "Current Release".  From the six releases
> in the package how is Andy supposed to decide what to download and
> install?

Good question, especially since the so called "Current Release" is 
actually ancient, and IMO, not nearly as good as some of the more 
recent "Technology Previews" or "Release Candidates".  My choice 
would be either the 6.8-3 release candidate, (for console mode GDB), 
or the insight-6.6 release candidate, (for a GUI variant).

> IMO, we need only one of each category displayed so when 
> the package maintainer uploads a new release he needs to hide the
> other releases in the same categories; other opinions?

In the case of "Current Release", definitely; it makes no sense at all 
to expose more than one of those.  Anything older than the most 
recent "Current Release" should be renamed as a "Previous Release", 
and all but the most recent of those should maybe also be hidden.

In the case of "Release Candidates", again it would make sense to 
expose only the most recent, since any others would presumably have 
been rejected as of unsatisfactory quality for release.

In the case of "Technology Previews", (which I consider to mean in 
either "alpha" or "beta" phase of development), then I think it makes 
more sense to expose the entire sequence, as alpha or beta testers 
may wish to readily access earlier releases for comparative 
evaluation.  However, once that series has progressed to the release 
candidate phase, then it makes sense to hide those preview releases.

This again raises the question of when a release should be promoted 
to "Current"; at present, we do not do this at all well.  It has been 
suggested, and I agree, that once the maintainer of a package has 
issued it as a release candidate, there should be an expectation that 
it will become the current stable release, after a finite interval.  
This is where we are failing; we have far too many packages which 
have remained as release candidates for far too long.  I have 
previously suggested three months as the cut-off interval; others 
have suggested that maybe one month would be more appropriate.  In 
either case, once the maintainer has provided a release candidate, 
the onus is on the user community to hit him with bug reports, WITHIN 
THE AGREED CUT-OFF PERIOD, if they don't agree that the package is 
ready for a "Current Release" designation.  In the absence of such 
bug reports, the onus is on the maintainer to complete the release, 
by marking it as "Current", when the cut-off period has lapsed.

On the preceding basis:

*  All GDB "Technology Preview" releases should now be hidden.

*  GDB-6.8-3 could now be promoted to "Current Release".

*  Insight-6.6 should be separated out from GDB-6.6, and offered
   as "Current Release".

*  GDB-6.6 should, at the very least, be promoted to "Current
   Release", (or to "Previous Release" if GDB-6.8-3 is promoted
   to "Current").

*  GDB-6.3 and GDB-5.2.1 should have been deprecated long ago.

Before I proceed on this basis, perhaps Brandon or Dave could comment 
on the suitability of their various releases for promotion.

Regards,
Keith.