All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trevor Woerner <trevor.woerner@linaro.org>
To: Martin Jansa <martin.jansa@gmail.com>,
	 openembedded-core@lists.openembedded.org,
	 openembedded-devel@lists.openembedded.org
Subject: Re: Quality of meta-oe metadata
Date: Sun, 30 Mar 2014 01:33:47 -0400	[thread overview]
Message-ID: <5337ACBB.4040804@linaro.org> (raw)
In-Reply-To: <20140330013103.GD2428@jama>

Hello Martin,

Excellent, excellent post!

On 03/29/14 21:31, Martin Jansa wrote:
> 2) There are a lot of changes and component upgrades in oe-core which
>    sometimes aren't very straight-forward to adapt to and issues stay in
>    meta-oe for months.

Critical bugfixes aside, I think the current system of unrestrained,
perpetual package bumps is an issue. If dylan uses version 1 of package
XYZ and dora uses version 5, is there any need for the 3 intervening
package bumps which occurred between the release of dylan and dora?

If nothing else, these "irrelevant updates" increase the chance of
causing problems ;-)

> 3) OE releases work great and don't invalidate sstate signatures so often, so my
>    feeling is that most developers and projects are just using releases and
>    less and less people do CI.

Would users prefer a better-tested more-likely-to-work release
containing package versions which were several months old, or is staying
on the bleeding edge more important? There is always exponentially more
work/cost required to be an early adopter.


WARNING: multiple messages have this Message-ID (diff)
From: Trevor Woerner <trevor.woerner@linaro.org>
To: Martin Jansa <martin.jansa@gmail.com>,
	 openembedded-core@lists.openembedded.org,
	 openembedded-devel@lists.openembedded.org
Subject: Re: [OE-core] Quality of meta-oe metadata
Date: Sun, 30 Mar 2014 01:33:47 -0400	[thread overview]
Message-ID: <5337ACBB.4040804@linaro.org> (raw)
In-Reply-To: <20140330013103.GD2428@jama>

Hello Martin,

Excellent, excellent post!

On 03/29/14 21:31, Martin Jansa wrote:
> 2) There are a lot of changes and component upgrades in oe-core which
>    sometimes aren't very straight-forward to adapt to and issues stay in
>    meta-oe for months.

Critical bugfixes aside, I think the current system of unrestrained,
perpetual package bumps is an issue. If dylan uses version 1 of package
XYZ and dora uses version 5, is there any need for the 3 intervening
package bumps which occurred between the release of dylan and dora?

If nothing else, these "irrelevant updates" increase the chance of
causing problems ;-)

> 3) OE releases work great and don't invalidate sstate signatures so often, so my
>    feeling is that most developers and projects are just using releases and
>    less and less people do CI.

Would users prefer a better-tested more-likely-to-work release
containing package versions which were several months old, or is staying
on the bleeding edge more important? There is always exponentially more
work/cost required to be an early adopter.


  reply	other threads:[~2014-03-30  5:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-30  1:31 Quality of meta-oe metadata Martin Jansa
2014-03-30  5:33 ` Trevor Woerner [this message]
2014-03-30  5:33   ` [OE-core] " Trevor Woerner
2014-04-01 11:21   ` Richard Purdie
2014-04-01 11:21     ` [OE-core] " Richard Purdie
2014-03-30 14:48 ` Paul Barker
2014-03-30 14:48   ` [OE-core] " Paul Barker
2014-03-30 15:14   ` Martin Jansa
2014-03-30 15:14     ` [OE-core] " Martin Jansa
2014-03-30 15:56     ` Paul Barker
2014-03-30 15:56       ` [OE-core] " Paul Barker
2014-03-30 16:09 ` Paul Barker
2014-03-30 16:09   ` [OE-core] " Paul Barker
2014-04-01 17:12 ` Mark Hatle
2014-04-01 17:40   ` Martin Jansa
2014-04-01 17:50     ` Mark Hatle

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=5337ACBB.4040804@linaro.org \
    --to=trevor.woerner@linaro.org \
    --cc=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --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.