All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joshua Lock <josh@openedhand.com>
To: Tom Zanussi <tom.zanussi@intel.com>
Cc: "poky@yoctoproject.org" <poky@yoctoproject.org>
Subject: Re: README.hardware
Date: Fri, 10 Dec 2010 11:42:09 +0000	[thread overview]
Message-ID: <1291981329.2483.1.camel@scimitar> (raw)
In-Reply-To: <1291923332.18502.158.camel@elmorro>

On Thu, 2010-12-09 at 13:35 -0600, Tom Zanussi wrote:
> On Thu, 2010-12-09 at 11:18 -0800, Gary Thomas wrote:
> > On 12/09/2010 12:08 PM, Joshua Lock wrote:
> > > On Wed, 2010-12-08 at 06:47 -0700, Gary Thomas wrote:
> > >> This file seems quite out of date, in fact it's not been updated
> > >> for 9 months :-(
> > >>
> > >> I don't know enough details to suggest a patch, but I think it
> > >> would be useful to update it to reflect "today's Poky/Yocto" world,
> > >> especially with the new visibility of the project.
> > >>
> > >
> > > I agree, although I'm also wondering if it would be better to have this
> > > information on the wiki where it can be more easily maintained by the
> > > community.
> > >
> > > Or a balance? any machine in meta/conf/machine documented in
> > > README.hardware and anything else on the wiki.
> > >
> > 
> > Wikis are great, but I tend to think of the Poky "checkout" tree
> > as self-sufficient.  It has the full manual, etc, already so forcing
> > the user to have to go to the Wiki for such information (which is
> > really only overview anyway) would not be ideal.  A combination
> > of hard files and Wiki would be OK as long as the README.hardware
> > at least mentions the "well sanctioned" ports, which right now
> > it does not.
> > 
> > I also tend to err on the side of my [sadly] many customers
> > that may have to work in non-internet-connected environments,
> > so making them have to get to a Wiki to find such answers is
> > not really acceptable.
> > 
> 
> I touched a bit on the current README.hardware in this posting, which
> suggests converting each machine into a BSP layer:
> 
> https://lists.yoctoproject.org/pipermail/poky/2010-December/001104.html
> 
> In that scheme, the individual sections in README.hardware would be
> moved into their own machine-specific READMEs for each BSP, keeping
> everything together.  The individual READMEs could also be made
> separately available on the 'BSP downloads' page and/or wiki for
> convenience.  Does that sound reasonable?

This sounds reasonable to me.

Cheers,
Joshua
-- 
Joshua Lock
        Intel Open Source Technology Centre



  reply	other threads:[~2010-12-10 11:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-08 13:47 README.hardware Gary Thomas
2010-12-09 19:08 ` README.hardware Joshua Lock
2010-12-09 19:18   ` README.hardware Gary Thomas
2010-12-09 19:35     ` README.hardware Tom Zanussi
2010-12-10 11:42       ` Joshua Lock [this message]
  -- strict thread matches above, loose matches on Subject: below --
2011-11-09 14:34 README.hardware James Abernathy
2011-11-09 14:41 ` README.hardware Paul Eggleton

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=1291981329.2483.1.camel@scimitar \
    --to=josh@openedhand.com \
    --cc=poky@yoctoproject.org \
    --cc=tom.zanussi@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.