Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>
Subject: Re: [PATCH] utils.bbclass: skip empty paths when handling FILESEXTRAPATHS
Date: Wed, 24 Aug 2011 18:24:57 -0700	[thread overview]
Message-ID: <1314235497.5939.166.camel@rex> (raw)
In-Reply-To: <CABcZANnGQBOwNVNRsgkH6akPrk9Sa_BoCsFtFBwTak9oRKfuPQ@mail.gmail.com>

On Wed, 2011-08-24 at 17:20 -0700, Chris Larson wrote:
> On Wed, Aug 24, 2011 at 5:16 PM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
> > On Thursday 25 August 2011 00:16:40 Chris Larson wrote:
> >> I strongly disagree with this. The fact is, we almost never go back
> >> and "clean these up later", so crap accrues.
> >
> > We're talking about the difference between:
> >
> > if a = "":
> >
> > and
> >
> > if a:
> >
> > This is not crap, it's a triviality (for the case where the functional
> > difference is not important anyway). If you care then by all means submit a
> > patch to change it.
> 
> Yes, this example is trivial, but its just one of many instances of
> this sort of code going in. I'd rather get the code clean to begin
> with, rather than letting crap pile up and never do anything about it.
> But I realize I care more about code quality than most of the people
> in this project.

I'm not sure that is true, I think many people care about the code
quality of OE. Quality means different things to different people. We
also all have different priorities. It would be nice in many ways if our
biggest worry was these sorts of issues but it isn't.

Also, we have a lot of new people looking at the project and starting to
contribute. People are learning a lot and becoming very skilled
developers, its exiting to watch some of their skill sets grow. Taking
an all or nothing approach to accepting patches tends to be
counterproductive. Educating people over time tends to work well.

I think these things will get addressed and get better in general over
time (and by many measures quality is improving already).

Cheers,

Richard




  reply	other threads:[~2011-08-25  1:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-19 12:16 [PATCH] utils.bbclass: skip empty paths when handling FILESEXTRAPATHS martin.jansa
2011-08-19 22:11 ` Chris Larson
2011-08-19 22:16   ` Martin Jansa
2011-08-22 13:01     ` Paul Eggleton
2011-08-24 23:16       ` Chris Larson
2011-08-25  0:16         ` Paul Eggleton
2011-08-25  0:20           ` Chris Larson
2011-08-25  1:24             ` Richard Purdie [this message]
2011-08-25  1:29               ` Chris Larson
2011-08-25  9:18   ` Phil Blundell
2011-08-25 13:49     ` Chris Larson
2011-08-24  3:41 ` Saul Wold

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=1314235497.5939.166.camel@rex \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul.eggleton@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox