public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jlarmour@redhat.com>
To: Alfredo Knecht <aknecht@cimsi.cim.ch>
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Re: eCos PCI problem and NEC vrc4373 build option.
Date: Wed, 30 Aug 2000 17:20:00 -0000	[thread overview]
Message-ID: <39ADA4CC.BD6FB3F0@redhat.com> (raw)
In-Reply-To: <3.0.5.32.20000831013839.00ace4c0@mailhost>

Alfredo Knecht wrote:
> 
> Jonathan, do you really mean that redhat is actually maintaining two
> separate threads of gdd/gdb/ecos, and that the one we're sweating on (I
> myself for one) is just some sort of bait?

No. We have tools here that we did QA with eCos on, and our compiler
engineers worked through the problems we found, fixed these bugs (i.e.
"stabilized" the sources). But most importantly, the bug fixes we found
were made to the free tools as well. And rightly so.

What we haven't done, and won't do, is continually track the free sources
to ensure no-one else then breaks the tools when used with eCos. If
problems are reported they'll be fixed (and not necessarily just by Red Hat
engineers of course), but we simply don't have the time to track every
change people make.

We try our best to fix what bugs we do find, and add improvements where we
can. But at the end of the day, it is up to the *whole* free software
community, Red Hat included, to make sure these tools are as good as they
can be.

But just to be clear - the sources Red Hat uses internally for eCos are
almost exactly the same as the public ones. The only differences are for
confidential information, ports for specific customers and unfinished code.
Ditto for gcc/gdb. There are no separate "threads". The only thing we do is
that we will occasionally "stabilize" a particular set of sources to ensure
they are of high quality for release to our customers. And all fixes
resulting from that stabilization are applied to the main free sources.
That doesn't count as a separate "thread".

> And all this in the name of the sacred open source, the plan being to get
> us hooked on the light and buggy weed, then sell us the harder stuff for
> real cash?

No the sources are of the same ilk. All that happened in this case is that
Red Hat took the time to internally stabilize the tools so that they
reliably worked with eCos. This took time, money and effort; but we still
ensured all the fixes found went into the free repository. We can't be
responsible if people subsequently broke things there again!

> This is an interesting business model indeed, and reminds me of another one.
> So, if I understand it right, the purpose of the open-source part including
> this list is to bring us to the point where we say "now that the project is
> late, we went this far, and invested all this time on that ecos thing,
> there is no alternative left" ...as to plunk down a lot of good money to
> get what was there all the time in the first place, namely the various
> shrink-wrapped products like VxWorks, Psos, QNX, and the like?
> 
> Or am I missing something eye-opening?

We try and provide free support when we have time - the activity on this
list should surely be proof of that! And not just from Red Hat folks
either. Plenty of people use eCos and the GNU tools with no problems. But
there are always going to be times when people have problems that are too
big for us to solve on the list. You can't really expect us to solve
everyone's problems!

Anyway, if you don't like it, you can get a full refund of everything you
paid :-). Seriously, this is the whole point - all the sources are there
for *you* to fix if you want. That's the power of open source for you. But
that doesn't mean you can expect someone else to fix things for you for
free!

Hope this clears things up,

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

  reply	other threads:[~2000-08-30 17:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-29 11:37 [ECOS] eCos tools binary installation under Cygwin Grant Edwards
2000-08-29 11:57 ` Jonathan Larmour
2000-08-29 12:28   ` Ling Su
2000-08-29 12:43     ` Jonathan Larmour
     [not found]       ` <39AC12F4.9C2F7678@redhat.co.uk>
2000-08-29 17:18         ` [ECOS] eCos PCI problem and NEC vrc4373 build option Ling Su
2000-08-30 15:25           ` [ECOS] " Jonathan Larmour
2000-08-30 15:51             ` Ling Su
2000-08-30 15:58               ` Jonathan Larmour
2000-08-30 16:38                 ` Alfredo Knecht
2000-08-30 17:20                   ` Jonathan Larmour [this message]
2000-08-30 18:10                     ` Alfredo Knecht
2000-08-30 18:22                       ` Jonathan Larmour
2000-08-30 17:42                   ` Ling Su
2000-08-30 18:02                     ` Jonathan Larmour
2000-08-30 18:28                       ` Ling Su
2000-08-30 18:57                         ` Jonathan Larmour
2000-08-31  3:34                           ` Nick Garnett
2000-08-31 10:57                           ` Ling Su

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39ADA4CC.BD6FB3F0@redhat.com \
    --to=jlarmour@redhat.com \
    --cc=aknecht@cimsi.cim.ch \
    --cc=ecos-discuss@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).