public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
From: "Drew M. Meeks" <drew@redhat.com>
To: sourcemaster@sources.redhat.com, overseers@sourceware.cygnus.com
Cc: cdelger@redhat.com, plindner@redhat.com
Subject: haiku + suggestion
Date: Mon, 10 Jul 2000 12:38:00 -0000	[thread overview]
Message-ID: <396A277E.2A90C2C@redhat.com> (raw)
Message-ID: <20000710123800.5D9HXwQMIFUhYB-U_cGsVG3FzqLp3rwJH45xsLQjcsU@z> (raw)

You asked for a haiku, you got it.
...............
Sources and DevNet
To make tools and to use tools
two sides of one coin
...............

Ok so the haiku stinks, but the idea I think is a good one. We need to
make sourceware/sources closer connected to redhat.com and vice versa. I
began this conversation with Jim Kingdon before he left and I think the
time is right to resume it.

I believe that sources.redhat.com and the Developer Network serve
different audiences and have different objectives but that they should
ultimately be deeply connected, much as two sides of the same coin.

The Developer Network's objective is to attract Programmers/Developers
to Red Hat's development platforms: for example, corporate and
commercial developers currently using NT. It's intended audience is the
users/potential users of our OS, compilers, debuggers, etc. not the
actual developers of those tools.

Sources.redhat.com, on the other hand, is clearly targeted at the people
who develop the tools themselves: the GNU/open source development
community. It is a resource to foster the ongoing development of these
tools, more than to encourage their adoption.

Since the audiences and objectives are different, I think it makes sense
to maintain the DevNet as the developer/programmer customer facing area
on the site and Sources as the tool/OS Developer facing area and to
provide meaningful links between the two. This they become like two
sides to one coin. 

The other aspect of this idea is to unify the hw/sw infrastructure. Paul
Lindner is heading up the development of a robust and dynamic
infrastructure for redhat.com. There are many excellent features that
already exist or are under development that Sources could benefit from.
Unifying the infrastructure would also more easily enable other
development groups within Red Hat to publish and maintain their public
Engineering project sites as part of Sources.

I would like to hear your thoughts on the matter and to help us arrive
at the right answer.

thanks for your time,

Drew

-- 
..........................................
drew meeks...............sr. web architect
products and platforms.....red hat, inc...
........................415.777.9810.x.222

             reply	other threads:[~2000-07-10 12:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-30  6:08 Drew M. Meeks [this message]
2000-07-10 12:38 ` Drew M. Meeks
2000-12-30  6:08 ` Chris Faylor
2000-07-10 17:26   ` Chris Faylor
2000-12-30  6:08 ` Jim Kingdon
2000-07-10 21:18   ` Jim Kingdon

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=396A277E.2A90C2C@redhat.com \
    --to=drew@redhat.com \
    --cc=cdelger@redhat.com \
    --cc=overseers@sourceware.cygnus.com \
    --cc=plindner@redhat.com \
    --cc=sourcemaster@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).