This is the mail archive of the gdb@sources.redhat.com 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: [commit] Deprecate remaining STREQ uses


On Mon, Dec 15, 2003 at 08:41:13AM +0200, Eli Zaretskii wrote:
> I agree that your suggestion will probably leave us with less bugs.
> But I'm concerned that we could inadvertently spill the baby, if we
> assume that any port that hasn't seen official testing does not work
> and should be obsoleted.

...

> The constructive action that could come out of this, in my view, is if
> we agree that hasty removal of support for platforms is potentially
> destructive and should be used with great caution.
> 
> What about others: am I the only one who thinks we shouldn't be
> obsoleting platforms hastily for lack of officially-certified testing?

This isn't a new issue, and it's not one with easy answers.  I also
think that Michael's stance is a little too harsh - good for an ideal
world, where we had more resources than we do (despite his absolutely
heroic efforts), but...

I am more interested in the removal of _unmaintained_ targets than in
the removal of _untested_ targets.  Normally these coincide; if they
don't for DJGPP then that's not a major problem to me.  We have a
couple of targets whose maintainers we haven't heard from in a while,
but they are likely to still work.  Looking at the list the only ones
I'm immediately worried about are d10v, mcore, mn10300, ns32k, v850,
vax.  Some of the others (like m32r) have seen a lot of activity.

I'd be terrified about sparc if Mark hadn't started to overhaul it.  I
remain worried about Solaris specifically.  We get a lot of Solaris
bug reports that go unanswered.

> My comment to this is that we should sometimes think about users, not
> only developers.  Being overly harsh to the users by removing support
> for their platforms too quickly is something I think we should avoid.

The alternative is finding that the platform hasn't actually worked in
three releases.

By the way, is there any reason DJGPP couldn't be tested in Bochs,
qemu, vmware, plex86, or some other new system emulator I haven't heard
of yet?  With qemu I suspect you could even make that scriptable, but
it would take some serious hacking - use the qemu console like a telnet
session.  Now that would be cool.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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