All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: Yocto Project and OE - Where now?
Date: Thu, 20 Jan 2011 14:16:42 +0100	[thread overview]
Message-ID: <AANLkTikJML8fawT9pBNH69V==E-4zDtMaTtsxPGQj07d@mail.gmail.com> (raw)
In-Reply-To: <4D3816BC.1010605@xora.org.uk>

2011/1/20 Graeme Gregory <dp@xora.org.uk>:
> On 20/01/2011 10:20, Frans Meulenbroeks wrote:
>>
>> And as said before, as a package maintainer I try to follow upstream
>> and support what upstream supports.
>> I do not want to take over the role of upstream wrt the package maintenance.
>> As a package maintainer I feel it as my task to make sure the version
>> from upstream builds in the OE environment, and ideally patches are
>> only there to deal with cross build issues, although every once in a
>> while a local bugfix is added.
>> That is how I see the role of a package maintainer, but others might
>> see things differently.
>> (btw for toolchain related things I can imagine we want to retain
>> older versions for a longer time, especially when there are functional
>> changes (I'm especially thinking about autohell))
>> And apologies if I sketch the things black and white, but at least
>> that makes things clear.
>> But also when it becomes to package maintainers tasks there is a gray area.
>>
> But this is part of the issue, this sort of working is fine for packages
> you maintain, but you try and force your opinions on which packages are
> relevant to other package maintainers. Go forth and do what you want
> with your own little area but at least give some consideration that I
> might actually be maintaining the recipes you class as junk.

Ehm, no. I don't want to enforce things onto others, and if you feel
you want to maintain 5 versions be my guest (assuming you maintain
them well)
And it is not up to me to give a classification of the work of others.
Then again I do not like it if people force maintenance work onto me
by pinning a version that I as a package maintainer feel should be
expired (for good reasons).

The real issues at hand are:
- we have quite a lot of recipes that were added at some point in time
but that are not maintained, apart from maybe sometimes getting a
small bug fix from someone actually passing by or caused by a global
change (e.g. adding md5sum's)
- maintainership of recipes is often unclear, so if there is an issue
it is unclear who to contact. To give an example: openssl: the last 15
commits in recipes/openssl are done by 10 different people.
MAINTAINERS does not list a maintainer for openssl. (and yeah, I know
I can send to the ML or contact the last committer)
- some maintainers don't do a very good job in maintaining, especially
when it comes to expiring old stuff, leaving a recipe that is not
fetchable, does not patch or does not build (sometimes because an .inc
file was modified and the patch works on the latest version, but older
versions are build let alone tested). I seem to recall a list from
Martin with some 1000 recipes on it that did not fetch or patch.
(actually not sure about the number). Updating also seems to be
lacking. Some action was taken then, but if I recall correctly this
was never completed.I

To get back at how well things are maintained, let us as an example
look at openssl again.

I've expired a number of versions that had known security
vulnerabilities last august. This gave a lot of flak as I accidently
deleted a version that was pinned (openssl_0.9.8m.bb). One of the
things observed at that time was that this version had CVE's and that
newer versions were available (9n and 9o). Currently (almost half a
year later) openssl is at 0.9.8q but OE is still at 0.9.8m.
I would have expected a maintainer would have taken action (and yes in
case of CVE's, I would suggest that the old versions with the security
issues are retired).
And I know way too well that we all are busy and have limited time,
but I would have hoped that someone would have taken action. And no,
it is not going to be me, I took enough heat on openssl last summer
and decided not to touch the recipe with a pole, but I would have
appreciated it that the people who gave me a hard time then at least
would have brought the recipe to 9o.
I explicitly mentioned .9o on aug 16.

Quote:
seems a good plan to upgrade to 0.9.8o though as it fixes some
security vulnerabilities

But that did not lead to action and at that point it seemed better for
me not to touch openssl at all (although I feel a security
vulnerability in something like openssl is quite serious).

And this is something that starts to irritate me in OE. apparently
there is always time to shoot the messenger who comes with suggestions
on how to improve, and to bash at people that at least try to resolve
some issues but the silence is deafening when it comes to actually
doing things.

And apologies if I sound a little bit sour.

Frans.



  reply	other threads:[~2011-01-20 13:18 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
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 [this message]
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='AANLkTikJML8fawT9pBNH69V==E-4zDtMaTtsxPGQj07d@mail.gmail.com' \
    --to=fransmeulenbroeks@gmail.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.