[oe] [PATCH 2/2] recipes: Update recipes to get 'bitbake world' parse and calculate runqueue successfully.

[Khem Raj]

On Sat, Aug 28, 2010 at 6:07 PM, Mike Westerhof <mike at mwester.net> wrote:
> Frans Meulenbroeks wrote:
>> Koen brought up this in the thread on the review process. As it
>> (mostly) is about this thread I felt it was more appropriate here.
> [snip]
>> I don't know what others think about it, but I see only a few matches.
> [snip]
>> PS: I think this is also an excellent case why it is a good idea to
>> identify the maintainer within the recipe/
>
> I think this gets at the heart of why Frans' recent changes make *me*
> uncomfortable -- their scope is broad and the general approach by Frans
> is to make everyone else provide detailed and precise arguments
> defending why the broad change should not apply to specific items.
>
> I, for one, would like to understand where this "cleanup" effort is
> ultimately going to go.  What distros will ultimately remain in OE?
> What what will be the final criteria for recipes being permitted to
> remain in OE (it seems to be converging on "it must build with bitbake
> world, despite the many emails that have offered sound reasons for why
> that is a poor test of recipe quality (which begs the question of why
> recipe buildability might be a valid measure of quality in the first
> place)).

>From a distro maintainer POV I can understand you point very well. I
don't feel strongly
about removal of recipes if they work and are old but I don't see any
value in a recipe which does not build in any combination either.
would you agree? Either we fix it or we can get rid of it as second choice.

I think bitbake world might be a far fetched goal but then I think it
speaks of health of the metadata.
(once bitbake world worked in OE) did we improve the situation by
making it unbuildable I dont think so.
and other distros do have these targets and they build too (e.g. freebsd)
I am afraid If we leave status quo then the cruft will keep piling up
and it will become really
unmanageable. Somewhere we need to bite the bullet. IMO OE should not
become a dumpyard of recipes where
you dig the ones that work and create a distro out of it but we should
try to make it a collection of working recipes(most of them) which
offers a wide set of recipes(different versions of same package or
different alternatives) to distros.
and all ideas are welcome to do it in a co-operative way. Lets make
sure that patches get reviewed here
and chance given to voice opinions and test patches by interested
parties before they get applied.

>
> Most of the patches and changes in OE have very specific distros in
> mind, or they set out to solve reasonably bounded problems when they
> cross distro boundaries.  Frans' changes do not.  The result is that
> each and every of these patches must be carefully reviewed.  I asked a
> specific question of Frans earlier that he did not answer, for whatever
> reason.  I'll ask again: What distros does Frans test to ensure that his
> patches are sane?
>
> It's great that we "clean up" OE, but in my opinion, it's being done
> with a sledgehammer approach, and I for one find it uncomfortable being
> "threatened" by the creator of these global giant patches setting
> policies about same that require the community to carefully defend their
> work or interests, or else.
>
> C'mon folks -- I'm not the only one who's busy, and who's uncomfortable
> with this.  Dev branch or not, this is NOT the way to get a community
> working together.
>
> -Mike (mwester)
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>