All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: openembedded-architecture
	<openembedded-architecture@lists.openembedded.org>,
	bitbake-devel <bitbake-devel@lists.openembedded.org>,
	Otavio Salvador <otavio.salvador@ossystems.com.br>
Subject: Re: [Openembedded-architecture] [PATCH] data_smart: Drop default expand=False to getVar [API change]
Date: Wed, 03 Feb 2016 16:22:32 +0000	[thread overview]
Message-ID: <1454516552.27087.197.camel@linuxfoundation.org> (raw)
In-Reply-To: <20160203150638.GB2567@jama>

On Wed, 2016-02-03 at 16:06 +0100, Martin Jansa wrote:
> On Wed, Feb 03, 2016 at 11:22:36AM +0000, Richard Purdie wrote:
> > On Wed, 2016-02-03 at 08:11 -0200, Otavio Salvador wrote:
> > > I am in favor of making it mandatory but I fail to see what we
> > > gain 
> > > in making it expand by default in future.
> > 
> > Less ugly syntax, in 99.9% of usages, you would want expand=True
> > and
> > getVar("X") is neater than getVar("X", True).
> 
> Consistent indentation is also neater than mixing tabs and spaces,
> but
> you were refusing to take such cosmetic change and now you're
> proposing
> neater getVar syntax which is (in some cases silently) breaking
> existing
> metadata and make backporting changes more difficult?
> 
> I'm not opposing the change, just don't understand why the same
> arguments work here and not for indentation.

If we go through the full transition, its possible something might
silently break, if they skip the release where we require a value. We
haven't reached that point yet and I'm honestly not sure how long we
should wait, I'm open to suggestions. The aim is to minimise any silent
failures though.

I'd also add that in many cases, it likely won't break at all, it might
potentially fix something. If there are concerns about this, there are
extra things we could consider such as requiring layers to mark they've
been validated for the change. That adds extra complexity, I'm less
sure about whether we need to do that.

As for your other point, whitespace in shell functions doesn't seem to
cause real world usability issues in that most people can read a tab
indented or space indented function equally well. OE-Core is pretty
consistent about what it uses and always has been, you personally just
don't like the particular choice made and meta-oe deciding to do
something else, contra to the TSC doesn't exactly help consistency. You
could argue meta-oe is more of the problem here.

The actual getVar syntax on the other handy is more than cosmetic,
people don't understand what this "True" they keep adding means, or why
they need it. You tend to know when you don't want expansion on the
other hand. So a cleaner syntax which does what the user most likely
needs is more than cosmetic.

Cheers,

Richard



  reply	other threads:[~2016-02-03 16:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-02 23:55 [PATCH] data_smart: Drop default expand=False to getVar [API change] Richard Purdie
2016-02-03 10:11 ` [Openembedded-architecture] " Otavio Salvador
2016-02-03 11:22   ` Richard Purdie
2016-02-03 15:06     ` Martin Jansa
2016-02-03 16:22       ` Richard Purdie [this message]
2016-02-03 16:29         ` Christopher Larson
2016-02-03 16:38           ` Richard Purdie
2016-02-03 16:52             ` Christopher Larson
2016-02-03 16:43       ` Otavio Salvador
2016-02-06  6:38 ` Paul Eggleton
2016-02-06  9:22   ` Richard Purdie

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=1454516552.27087.197.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=martin.jansa@gmail.com \
    --cc=openembedded-architecture@lists.openembedded.org \
    --cc=otavio.salvador@ossystems.com.br \
    /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.