All of lore.kernel.org
 help / color / mirror / Atom feed
From: Khem Raj <raj.khem@gmail.com>
To: richard.purdie@linuxfoundation.org
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 16/19] meson: update to 0.52.0
Date: Sun, 20 Oct 2019 06:51:26 +0530	[thread overview]
Message-ID: <CAMKF1sr8xy+bW_UL_=B-nt7MG58bJj=WmB9VVZf5hxBqpXwPiQ@mail.gmail.com> (raw)
In-Reply-To: <da2fa30bb8fed7f991ef14a4955a67ec15bc94a6.camel@linuxfoundation.org>

[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]

On Sat, Oct 19, 2019 at 2:56 AM <richard.purdie@linuxfoundation.org> wrote:

> On Fri, 2019-10-18 at 20:49 +0200, Alexander Kanavin wrote:
> > I certainly don't mean to ignore those reports, it's just that due to
> > my ongoing health problems, and having to dedicate most of my energy
> > to the day job (https://mbition.io/en/home/), I am not currently able
> > to work on the upstream issues in a timely manner the way I used to
> > when maintaining core was actually my day job (at Intel).
> >
> > The question of how much effort people who update things in core
> > should allocate to fixing 'other' layers has been a conflict point
> > for a long time. I'd prefer to see more aggressive
> > blacklisting/removal of recipes that no one has an interest in fixing
> > and updating.
>
> If anything this would be my fault for merging things despite there
> being concerns raised. I have to admit I'd seen other patches and
> therefore erroneously thought the issues we mostly resolved.
>
> Should OE-Core block on all issues being resolved before merging? I'm
> torn on that, I realise there are pros and cons.


If an issue is there and gets reported after it’s merged I think it’s fine
to do whatever is needed after the fact however if testing master-next from
oe-core and reported against it I think this will help you in longer run if
these master-next issues are looked into and blocked on. We should not run
Oe-core so fast that other layers fall way back behind where they start
supporting just releases and you have lost free integration testing that
other layers would offer

If there are too many reports then it would be questionable to block on it
but I don’t think that’s the case



>
> It takes most of my time/energy to track the issues with core without
> trying to remember that patch X breaks layer Y and that I need a report
> back on that combination before I then find a patch and merge it.
>
> So sorry, I probably shouldn't have taken this :/.
>
> There is a fundamental issue with having enough people to help work on
> these things though and requiring more work for changes to be merged
> isn't going to help. I wish I knew what would help.
>
> Cheers,
>
> Richard
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 3018 bytes --]

  reply	other threads:[~2019-10-20  1:21 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-11 11:47 [PATCH 01/19] runqemu: add options that enable virgl with the SDL frontend Alexander Kanavin
2019-10-11 11:47 ` [PATCH 02/19] oe-selftest: extend virgl gtk test to also check the SDL option Alexander Kanavin
2019-10-11 11:47 ` [PATCH 03/19] runqemu: unset another environment variable for 'egl-headless' Alexander Kanavin
2019-10-11 11:47 ` [PATCH 04/19] gobject-introspection: update to 1.62.0 Alexander Kanavin
2019-10-11 11:47 ` [PATCH 05/19] glib-2.0: upgrade to 2.62.1 Alexander Kanavin
2019-10-12 20:59   ` Khem Raj
2019-10-12 22:32     ` Khem Raj
2019-10-13  0:57   ` Khem Raj
2019-10-13  1:18   ` Khem Raj
2019-10-11 11:47 ` [PATCH 06/19] glib-networking: update " Alexander Kanavin
2019-10-11 11:47 ` [PATCH 07/19] sysprof: update to 3.34.1 Alexander Kanavin
2019-10-11 11:47 ` [PATCH 08/19] epiphany: upgrade 3.32.4 -> 3.34.1 Alexander Kanavin
2019-10-11 11:47 ` [PATCH 09/19] webkitgtk: update 2.24.4 -> 2.26.1 Alexander Kanavin
2019-10-11 14:39   ` Khem Raj
2019-10-11 11:47 ` [PATCH 10/19] gtk-doc: upgrade 1.31 -> 1.32 Alexander Kanavin
2019-10-11 19:30   ` akuster808
2019-10-11 19:39     ` Alexander Kanavin
2019-10-12 10:12       ` Adrian Bunk
2019-10-11 11:47 ` [PATCH 11/19] libdazzle: upgrade 3.32.3 -> 3.34.1 Alexander Kanavin
2019-10-11 11:47 ` [PATCH 12/19] libsecret: upgrade 0.19.0 -> 0.19.1 Alexander Kanavin
2019-10-11 11:47 ` [PATCH 13/19] mpg123: upgrade 1.25.11 -> 1.25.12 Alexander Kanavin
2019-10-11 11:47 ` [PATCH 14/19] p11-kit: upgrade 0.23.16.1 -> 0.23.18.1 Alexander Kanavin
2019-10-11 11:47 ` [PATCH 15/19] vala: upgrade 0.44.7 -> 0.46.3 Alexander Kanavin
2019-10-11 11:47 ` [PATCH 16/19] meson: update to 0.52.0 Alexander Kanavin
2019-10-13  0:20   ` Khem Raj
2019-10-17 13:15     ` Khem Raj
2019-10-17 23:31       ` Andreas Müller
2019-10-18 18:49       ` Alexander Kanavin
2019-10-18 21:26         ` richard.purdie
2019-10-20  1:21           ` Khem Raj [this message]
2019-10-20  9:50             ` richard.purdie
2019-10-20 12:32             ` richard.purdie
2019-10-20 15:08               ` Andreas Müller
2019-10-20 15:53                 ` Andreas Müller
2019-10-22  7:30                   ` Andreas Müller
2019-10-18 22:01         ` Andreas Müller
2019-10-18 22:19           ` Richard Purdie
2019-10-11 11:47 ` [PATCH 17/19] libmodulemd-v1: introduce the recipe Alexander Kanavin
2019-10-11 11:47 ` [PATCH 18/19] libmodulemd: remove " Alexander Kanavin
2019-10-11 11:47 ` [PATCH 19/19] createrepo-c: upgrade to 0.15.1 Alexander Kanavin

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='CAMKF1sr8xy+bW_UL_=B-nt7MG58bJj=WmB9VVZf5hxBqpXwPiQ@mail.gmail.com' \
    --to=raj.khem@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.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.