Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Trevor Woerner <trevor.woerner@linaro.org>
Cc: openembedded-devel@lists.openembedded.org,
	openembedded-core@lists.openembedded.org
Subject: Re: Quality of meta-oe metadata
Date: Tue, 01 Apr 2014 12:21:18 +0100	[thread overview]
Message-ID: <1396351278.2910.5.camel@ted> (raw)
In-Reply-To: <5337ACBB.4040804@linaro.org>

On Sun, 2014-03-30 at 02:33 -0400, Trevor Woerner wrote:
> 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?

To put the other side of the argument to this, if you leave things and
just update once, you bring in more change and it usually ends up being
progressively harder to debug any issues since more things changed and
you don't know which change caused which problem.

OE-Core has there fore gone for the "update regularly" philospohy where
we can. This means we get to know about issues earlier and have more
time to fix them, they're also less likely to get confused with other
bugs.

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

I'd disagree :)

> > 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.

At least for OE-Core, there is a strong pressure to try and keep up to
date. The stability is found in the release branches one a set of
versions are locked in.

If we run into problems and talk to upstreams, the invariable question
was "does this reproduce with the last release (or head of SCM)?". If
we're up to date, it makes it easier for us to talk to upstreams in that
regard too.

Cheers,

Richard







  reply	other threads:[~2014-04-01 11:21 UTC|newest]

Thread overview: 10+ 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
2014-04-01 11:21   ` Richard Purdie [this message]
2014-03-30 14:48 ` Paul Barker
2014-03-30 15:14   ` Martin Jansa
2014-03-30 15:56     ` Paul Barker
2014-03-30 16:09 ` 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=1396351278.2910.5.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=trevor.woerner@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox