All of lore.kernel.org
 help / color / mirror / Atom feed
From: Koen Kooi <koen@dominion.thruhere.net>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [meta-oe][PATCH V2 6/7] blacklist.bbclass: Move to meta-angstrom
Date: Mon, 06 Aug 2012 09:43:51 +0200	[thread overview]
Message-ID: <jvnsim$5e9$1@dough.gmane.org> (raw)
In-Reply-To: <CABcZANnEmASgH3wrk7TZOpe3BaK+o6oRPyvAo6SadtybgqDWJg@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 05-08-12 23:37, Chris Larson schreef:
> On Sun, Aug 5, 2012 at 4:41 AM, Koen Kooi <koen@dominion.thruhere.net>
> wrote:
>>> doent sound logical to me. Would it be acceptable if angstrom used
>>> this feature from OE-Core as well ? then it will remove the usecase 
>>> completely.
>> 
>> I keep waiting on the person that pushed it to oe-core to provide
>> patches for distro layers using the old functionality, see above.
> 
> This doesn't make much sense to me. It's impossible to know what all 
> layers use a given piece of functionality, particularly ones that aren't
> published in public places, so expecting every person changing something
> in oe-core will go and submit changes to every layer that exists is
> entirely unreasonable. If you maintain a layer, it's your responsibility
> to make sure your layer retains compatibility with upstream. It's not
> upstream's responsibility to make sure everyone using their functionality
> stays compatible.

In this specific instance the class was moved from meta-angstrom to meta-oe
as is and then moved to oe-core and changed to make it "less angstrom
specific".
I don't see how you can  argue that the person making that change was/is
unaware of the existence of the angstrom layer. Or of the SHR usage of that
class.

But yes, some people don't know that layers exist, there was a nice example
last week when I asked if someone checked *all* the layers out there on the
impact of the patch in question and the response was "Yes, I checked both
oe-core and meta-intel".

I agree with your generic point that changes in oe-core can not and should
not require updating of all layers by the submitter. On the other hand: if
you know you're moving functionality between layers while breaking it in the
process it is anti-social to not fix up the user(s) of that functionality
that you know of.

This is similar to asking a oe-core patch to be held back for a few days
because a number of layers have a matching bbappend that will need updating.
Especially if those layers have maintainers where the patch review latency
is measured in days instead of hours (e.g. me with non-denzil based stuff).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFQH3W3MkyGM64RGpERAlbgAKCBvZTQD38H44mB+JzjQ2t92ttMzQCfVxeJ
nX2o+AfM7mrFEZnBT7YAV5s=
=v8kK
-----END PGP SIGNATURE-----




  parent reply	other threads:[~2012-08-06  7:55 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-31 18:56 [meta-systemd][PATCH V2 1/7] systemd: Upgrade to 187 Khem Raj
2012-07-31 18:56 ` [meta-systemd][PATCH V2 2/7] busybox: stopping systemd-kmsg-syslogd is not needed Khem Raj
2012-07-31 18:56 ` [meta-systemd][PATCH V2 3/7] busybox-syslog.service.in: Create alias for syslog.service Khem Raj
2012-07-31 18:56 ` [meta-systemd][PATCH V2 4/7] systemd: Use cross cpp Khem Raj
2012-07-31 18:56 ` [meta-oe][PATCH V2 5/7] testlab.bbclass: Delete Khem Raj
2012-07-31 18:56 ` [meta-oe][PATCH V2 6/7] blacklist.bbclass: Move to meta-angstrom Khem Raj
2012-07-31 19:07   ` Koen Kooi
2012-07-31 19:24     ` Chris Larson
2012-07-31 19:43     ` Martin Jansa
2012-07-31 20:46       ` Khem Raj
2012-08-04 20:36   ` Koen Kooi
2012-08-04 20:47     ` Khem Raj
2012-08-04 21:56       ` Philip Balister
2012-08-05 11:41       ` Koen Kooi
2012-08-05 19:44         ` Khem Raj
2012-08-05 21:37         ` Chris Larson
2012-08-05 22:06           ` Khem Raj
2012-08-06  7:43           ` Koen Kooi [this message]
2012-08-07  2:38             ` Khem Raj
2012-07-31 18:56 ` [meta-oe][PATCH V2 7/7] kernel.bbclass: Rename to machine_kernel_pr.bbclass which provides added functionality Khem Raj
2012-08-01 17:38   ` Otavio Salvador
2012-08-01 22:31     ` Khem Raj
2012-08-01 15:11 ` [meta-systemd][PATCH V2 1/7] systemd: Upgrade to 187 Koen Kooi
2012-08-01 22:56   ` Khem Raj
2012-08-02  8:11     ` Paul Eggleton
2012-08-03 10:32       ` Khem Raj
2012-08-03 12:38         ` Koen Kooi
2012-08-03 14:41           ` Khem Raj
2012-08-03 15:36             ` Koen Kooi
2012-08-03 18:39               ` Khem Raj
2012-08-03 18:42                 ` Martin Jansa
2012-08-03 19:08                 ` Koen Kooi
2012-08-04 20:10               ` Khem Raj
2012-08-04 20:35                 ` Koen Kooi
2012-08-04 20:50                   ` Khem Raj
2012-08-05 11:42                     ` Koen Kooi
2012-08-05 11:53                       ` Philip Balister
2012-08-05 19:40                         ` Khem Raj

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='jvnsim$5e9$1@dough.gmane.org' \
    --to=koen@dominion.thruhere.net \
    --cc=openembedded-devel@lists.openembedded.org \
    /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.