All of lore.kernel.org
 help / color / mirror / Atom feed
From: C Michael Sundius <msundius@sundius.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: Yocto Project and OE - Where now?
Date: Wed, 19 Jan 2011 13:55:45 -0800	[thread overview]
Message-ID: <AANLkTimyPb-4pLrbF4ZeFwnh+9WyZtcPY1uXeYBnwUqQ@mail.gmail.com> (raw)
In-Reply-To: <AANLkTimMHd-eH9tEL1tUtoUKa+zwX4+9kUdT3k_NP9nG@mail.gmail.com>

It seems to me that this is a bit of a battle between the package
maintainers and the distro maintainers.. Looking at this from my managements
side of things, we use OE as a tool and its really just a means to the end.
our customers demand that we do not change things (versions of software),
they demand stability and they view a change in busybox or anything else a
threat to stability. our management has also made an edict that we can not
use gplv3. For completely non technical reasons we simply cannot move to new
package versions without a substantial business justification. I suspect
that that there are many (more than you realize) folk out there who are
using OE for their own distro. If you simply whack package versions because
something newer came out you will have these people maintaining separate
recipes and we'll be swamped with the load and this tool will loose one of
its best attributes.

The comment that disturbed me was that distros should just move ahead
"because its making things hard for the package maintainer". That doesn't
wash with me because if people are using your package then you should
support it or let someone else be the maintainer. In essence the distro's
use of that package are your customers and the reason you have a job. OE
does not exist as a product, rather a tool that enables customers, you can't
create this in a vacuum without understanding who is using it.

distro maintainers are not all dumb and if they are they'll be the last
single one using an outdated version of the software. When that happens a
smart package maintainer will call it out leave out the old package.
Further, it would be nice for a warning to take place so that it might have
a "depracated" tag associated with the recipe for one release cycle to see
if anyone cribs.

So I'm standing with the guy w/ asbestos short on. I'd like to see that OE
err on the side of "do no harm" to existing users. Its hard enough to rally
the troops to move to updated packages much less updated meta without you
leaving perfectly reasonable versions of software out of oe-core.

mike


  reply	other threads:[~2011-01-19 21:56 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-14 17:49 Yocto Project and OE - Where now? Richard Purdie
2011-01-17 15:15 ` Koen Kooi
2011-01-17 19:01 ` Frans Meulenbroeks
2011-01-18  7:21   ` Graeme Gregory
2011-01-18  8:05     ` Otavio Salvador
2011-01-18  8:47       ` Koen Kooi
2011-01-18  9:17         ` Richard Purdie
2011-01-18  9:12       ` Graeme Gregory
2011-01-18 10:15         ` Richard Purdie
2011-01-18 11:05           ` Frans Meulenbroeks
2011-01-18 11:31       ` Mark Brown
2011-01-18 18:45         ` Frans Meulenbroeks
2011-01-18 16:54       ` Tom Rini
2011-01-18 20:12         ` Koen Kooi
2011-01-18 20:48           ` Tom Rini
2011-01-18 22:05             ` Koen Kooi
2011-01-19  8:45               ` Frans Meulenbroeks
2011-01-19  8:58                 ` Graeme Gregory
2011-01-19  9:16                   ` Frans Meulenbroeks
2011-01-19  9:25                 ` Frans Meulenbroeks
2011-01-22 18:16                   ` Tom Rini
2011-01-23 10:11                     ` Frans Meulenbroeks
2011-01-24 17:45                       ` Tom Rini
2011-01-18 22:48             ` Khem Raj
2011-01-19  8:46               ` Frans Meulenbroeks
2011-01-19  8:52                 ` Graeme Gregory
2011-01-19  9:12                   ` Frans Meulenbroeks
2011-01-19  9:19                     ` Graeme Gregory
2011-01-19 11:31                     ` Joshua Lock
2011-01-19 12:44                       ` Frans Meulenbroeks
2011-01-19 15:09                         ` Mike Westerhof
2011-01-19 15:44                           ` Frans Meulenbroeks
2011-01-19 18:03                           ` Khem Raj
2011-01-19 21:55                             ` C Michael Sundius [this message]
2011-01-19 22:01                               ` C Michael Sundius
2011-01-19 22:22                                 ` Philip Balister
2011-01-19 22:23                               ` Khem Raj
2011-01-19 22:46                                 ` C Michael Sundius
2011-01-20 10:20                                 ` Frans Meulenbroeks
2011-01-20 11:04                                   ` Graeme Gregory
2011-01-20 13:16                                     ` Frans Meulenbroeks
2011-01-19 16:56                 ` Khem Raj
2011-01-22 18:20                 ` Tom Rini
2011-01-23  2:05                   ` Otavio Salvador
2011-01-19  7:47           ` Frans Meulenbroeks
2011-01-19  8:16             ` Martin Jansa

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=AANLkTimyPb-4pLrbF4ZeFwnh+9WyZtcPY1uXeYBnwUqQ@mail.gmail.com \
    --to=msundius@sundius.com \
    --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.