TSC Meeting 2010/03/02

TSC Meeting 2010/03/02

[Richard Purdie]

TSC Meeting 2010/03/02

We moved the time to Tuesday since I couldn't make Thursday.
Unfortunately Mickey couldn't make Tuesday due to a last minute meeting
but four of us met anyway to discuss various issues. The outcome of
various topics was:

Code of Conduct
===============

We agreed we need one but also that its outside the remit of what the
TSC should be discussing. We don't feel something heavy and draconian
with every action spelt out is a sensible idea but we should have some
guidelines behaviour can be judged against. In this respect we could do
a lot worse than adopt the Ubuntu CoC
(http://www.ubuntu.com/community/conduct).

We'd like to propose to the e.V. board and members that the Ubuntu CoC
should be adopted (wording adjusted to suit OE) by the OE e.V.

The one problem here is that we don't have a community council. The TSC
could serve as this but we'd prefer to split this work to a dedicated
group. We'd like to ask the members to discuss this and see what people
feel is the best thing to do.

Elections
=========

We agreed to hold TSC elections in April which means calling for
candidates soon. We'd like to see active people wanting to move OE
forward and would love to see come competition for the TSC places. Now
we've established the format and input required hopefully more people
will feel comfortable coming forward. For more information about what
the role involves please talk to any existing TSC member.

Angstrom
========

People do seem to use Angstrom as a target for certain discussions. The
people involved have got on and made a success of a distribution and
people should respect that. There are some customisations which could be
more generic so other people would be more comfortable using them. These
should be discussed and the Angstrom devs are amenable to that but
breaking Angstrom for the benefit of others isn't really fair.

Splitting Angstrom into its own directories (e.g. for images) is going a
full circle as Angstrom did have that and was coerced into merging
things. No solution will please everyone but before the TSC can get
involved, discussions need to happen with clear proposals. Angstrom is
not perfect but it has gone out there and achieved things which is worth
keeping in mind.

Developer Effort
================

Rather than discussions such as the above, how about injecting that
energy into adopting the new staging, BBCLASSEXTEND and -nativesdk code?

BBLayers
========

Mentioned briefly, no concerned we raised above those expressed already.
Having coherent layer handling is desirable and the bitbake team will
continue its work accordingly.

Other Business
==============

Apologies have been made to the TSC for my absence at the last meeting.
There was some confusion on my part over the protocols and I didn't 
think the meeting was happening.


Regards,

Your TSC

Graeme Gregory (XorA)
Koen Kooi
Chris Larson (kergoth)
Michael 'Mickey' Lauer (mickeyl)
Richard Purdie (RP)

Re: TSC Meeting 2010/03/02

[Frans Meulenbroeks]

Richard, thanks for the report.

There are some remarks I want to make, see below.

2010/3/3 Richard Purdie <rpurdie@rpsys.net>:
> TSC Meeting 2010/03/02
[...]
>
> Developer Effort
> ================
>
> Rather than discussions such as the above, how about injecting that
> energy into adopting the new staging, BBCLASSEXTEND and -nativesdk code?

Ehm. there was already a similar remark in the recent pango thread
(angstrom: sync pango and pango-native versions)

I'd say the tone in that email and in the two lines above does not
really meet the 'be considerate" and 'be respectful' as described in
the ubuntu code of conduct.
Also note that most of the work is done by
volunteers/hobbyists/whatever you want to name them.
I feel it is not really for the TSC (or for me) to say what others
should do. Suggestions could be made but I think it could be worded
more polite.

And wrt the new staging/BBCLASSEXTEND/nativesdk topic:
In my opinion it is useful to clean up the existing recipes (or move
them to 'obsolete' or whatever).
That way less recipes need to be adopted, and no energy is wasted on
adopting legacy recipes.
(apart from the fact that having lots of recipes for lots of variants
does not really give a professional and mature impression).

BTW: The recipes I feel responsible for are all converted to both new
staging and BBCLASSEXTEND.
I have considered converting some of the others to new staging.
Actually I even started it, but soon stopped with it for the following
reasons:
- the actual verification process is fairly cumbersome. (5) diff the 2
packaged-staging recipes (which I read as packaged-staging packages as
there are no packaged-staging recipes) is imho a pita)
- i have no idea what recipes are actually used and worthwhile my effort
- some people seem to be picky if you touch their recipes (although
some are a lot less considerate when it comes to recipes of others :-(
)
Together for me that has lead to the conclusion that this is work with
low satisfaction and high chance of getting negative feedback (e.g.
because despite your efforts something breaks, or because by accident
you step on someones toes), and that I'd better work on something
else.

Frans.

PS: and wrt the remark "we have been discussed this before and the
conclusion then was...": great, but if you do not document those
decisions they will pop up every once in a while (e.g. by someone who
is not aware of the decision; e.g. I for me, was unaware that angstrom
initially had its own directory).

Re: TSC Meeting 2010/03/02

[Marcin Juszkiewicz]

Dnia środa, 3 marca 2010 o 13:59:19 Frans Meulenbroeks napisał(a):
> - the actual verification process is fairly cumbersome. (5) diff the 2
> packaged-staging recipes (which I read as packaged-staging packages as
> there are no packaged-staging recipes) is imho a pita)
 
I am comparing two IPK packages using midnight commander. Fast and easy.

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: TSC Meeting 2010/03/02

[Richard Purdie]

On Wed, 2010-03-03 at 13:59 +0100, Frans Meulenbroeks wrote:
> 2010/3/3 Richard Purdie <rpurdie@rpsys.net>:
> > Developer Effort
> > ================
> >
> > Rather than discussions such as the above, how about injecting that
> > energy into adopting the new staging, BBCLASSEXTEND and -nativesdk code?
> 
> Ehm. there was already a similar remark in the recent pango thread
> (angstrom: sync pango and pango-native versions)
> 
> I'd say the tone in that email and in the two lines above does not
> really meet the 'be considerate" and 'be respectful' as described in
> the ubuntu code of conduct.

The wording could perhaps be better but I don't think its bad enough
that it falls foul of the CoC.

The TSC fully appreciates the work people put into OE and is just
frustrated so much energy gets lost on what amount to relatively minor
issues where there are many other things that need work.

Put things into context - is whether a variable name has the word
angstrom in the name really a massive insurmountable problem stopping
people from using OE?

> Also note that most of the work is done by
> volunteers/hobbyists/whatever you want to name them.
> I feel it is not really for the TSC (or for me) to say what others
> should do. Suggestions could be made but I think it could be worded
> more polite.

The above is simply a suggestion. The TSC in no way controls what
volunteers/hobbyists/employees/companies or anyone else working on OE
actually works on. We can make a suggestion of where we feel effort
would be well spent which is what the above states.

No matter how many policies, groups or anything else we put into place
this is an open source project which by the nature anyone is free to do
pretty much anything. This can and does lead to friction at times and
people do have strong opinions which there are no plans to censor. What
we do need to stop is the personal attack side of things. "Attacking"
someone's proposal on technical grounds is perfectly fair game IMO as
long as it has a constructive and/or reasoned basis. The one thing it
should never be is personal.

> And wrt the new staging/BBCLASSEXTEND/nativesdk topic:
> In my opinion it is useful to clean up the existing recipes (or move
> them to 'obsolete' or whatever).
> That way less recipes need to be adopted, and no energy is wasted on
> adopting legacy recipes.
> (apart from the fact that having lots of recipes for lots of variants
> does not really give a professional and mature impression).

Legacy recipes are a source of contention. We're bad at tracking who
needs them and why. There some some factions of OE who'd like to never
see any recipe deleted and there are some who feel any old recipe should
be removed.

We do have a problem in that the people who use old recipes use them as
they don't like change and the staging changes are change and hence we
either don't convert them (and hence never complete the transition we
*need* to make) or we convert them and cause those people pain anyway.

I could see a case for having a mass clear out of old recipes in OE to
get the new staging changes in. Anyone wanting old versions could either
add them back specifically (converted), make sure they were converted by
a deadline or use an older tree. Someone would have to take an effort
like that on, announce it and lead it but I suspect it could actually be
made to work. It will need some time commitment though, any
volunteers? :)

> BTW: The recipes I feel responsible for are all converted to both new
> staging and BBCLASSEXTEND.

Great, thanks for doing that!

> I have considered converting some of the others to new staging.
> Actually I even started it, but soon stopped with it for the following
> reasons:
> - the actual verification process is fairly cumbersome. (5) diff the 2
> packaged-staging recipes (which I read as packaged-staging packages as
> there are no packaged-staging recipes) is imho a pita)

It would be better to have some kind of automated way of doing this I
agree. Its technically possible, just nobody has found the time needed
to implement it. We're all volunteers as you point out.

> - i have no idea what recipes are actually used and worthwhile my effort

Ultimately its desirable to convert everything.

> - some people seem to be picky if you touch their recipes (although
> some are a lot less considerate when it comes to recipes of others :-(
> )

There are ways of handling this (RFC the patches, delay the commit for a
few days. If no answer, then make the changes).

> Together for me that has lead to the conclusion that this is work with
> low satisfaction and high chance of getting negative feedback (e.g.
> because despite your efforts something breaks, or because by accident
> you step on someones toes), and that I'd better work on something
> else.

Well, we all feel like this at times. If I took all the negative stuff I
see about my work to heart, I'd not be doing it. Hopefully people do
feel some of the things I've done are some kind of benefit to OE. I have
broken things before, I probably will again despite my best efforts but
its how you deal with these things the people ultimately judge you on.

I have yet to see a "thank you for helping set up the TSC, getting
involved in the nastiest arguments OE has and putting your neck on the
line all the time email" and don't expect one either. I doubt the e.V.
board has either but for the record I do appreciate what they do and am
trying to do my bit through the TSC.

> PS: and wrt the remark "we have been discussed this before and the
> conclusion then was...": great, but if you do not document those
> decisions they will pop up every once in a while (e.g. by someone who
> is not aware of the decision; e.g. I for me, was unaware that angstrom
> initially had its own directory).

Document where? How? Do you document the outcome of every email
discussion you have on the OE list? It was a "decision" that came about
as the result of an email discussion on this mailing list, nothing more,
nothing less. Volunteers doing this would be very welcome...

Cheers,

Richard

Re: TSC Meeting 2010/03/02

[Martin Jansa]

On Wed, Mar 03, 2010 at 01:47:42PM +0000, Richard Purdie wrote:
> > I have considered converting some of the others to new staging.
> > Actually I even started it, but soon stopped with it for the following
> > reasons:
> > - the actual verification process is fairly cumbersome. (5) diff the 2
> > packaged-staging recipes (which I read as packaged-staging packages as
> > there are no packaged-staging recipes) is imho a pita)
> 
> It would be better to have some kind of automated way of doing this I
> agree. Its technically possible, just nobody has found the time needed
> to implement it. We're all volunteers as you point out.

Today while checking diff of pango and libxml I noticed that bumping
PR/INC_PR to target value before building it the old way helps a lot.

Even the binaries were a bit different when they were built from
different workdir because of PR (probably because of unstripped data in
workdir/image).

So now I first bump PR/INC_PR to target combination, then build without
BBCLASSEXTEND without rm_work inherit or -c build, backup workdir, make
BBCLASSEXTEND change, -c clean, -c build, and diff -rq workdir with
backuped version.

If it's different only in temp/run* temp/log* then it's great :). But
usually static libs are still a bit different but probably in harmless
way.

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: TSC Meeting 2010/03/02

[Frans Meulenbroeks]

2010/3/3 Richard Purdie <rpurdie@rpsys.net>:
> On Wed, 2010-03-03 at 13:59 +0100, Frans Meulenbroeks wrote:
>> 2010/3/3 Richard Purdie <rpurdie@rpsys.net>:
>> > Developer Effort
>> > ================
>> >
>> > Rather than discussions such as the above, how about injecting that
>> > energy into adopting the new staging, BBCLASSEXTEND and -nativesdk code?
>>
>> Ehm. there was already a similar remark in the recent pango thread
>> (angstrom: sync pango and pango-native versions)
>>
>> I'd say the tone in that email and in the two lines above does not
>> really meet the 'be considerate" and 'be respectful' as described in
>> the ubuntu code of conduct.
>
> The wording could perhaps be better but I don't think its bad enough
> that it falls foul of the CoC.

For the wording above I agree.
The message in the pango thread, I felt as a snide remark directed
directly to me (as I initiated the discussions).
>
> The TSC fully appreciates the work people put into OE and is just
> frustrated so much energy gets lost on what amount to relatively minor
> issues where there are many other things that need work.
>
> Put things into context - is whether a variable name has the word
> angstrom in the name really a massive insurmountable problem stopping
> people from using OE?

I have not too much problems with the variable name as is.
My intention was sincere and I felt that I was just following the procedure.
Then someone started to claim that as author of the recipe he was not
consulted and claimed he had the final say in it.
Fine with me, but then please make clear what recipes you "own" and
move them out of the common area.
>
>> Also note that most of the work is done by
>> volunteers/hobbyists/whatever you want to name them.
>> I feel it is not really for the TSC (or for me) to say what others
>> should do. Suggestions could be made but I think it could be worded
>> more polite.
>
> The above is simply a suggestion. The TSC in no way controls what
> volunteers/hobbyists/employees/companies or anyone else working on OE
> actually works on. We can make a suggestion of where we feel effort
> would be well spent which is what the above states.
>
> No matter how many policies, groups or anything else we put into place
> this is an open source project which by the nature anyone is free to do
> pretty much anything. This can and does lead to friction at times and
> people do have strong opinions which there are no plans to censor. What
> we do need to stop is the personal attack side of things. "Attacking"
> someone's proposal on technical grounds is perfectly fair game IMO as
> long as it has a constructive and/or reasoned basis. The one thing it
> should never be is personal.

I fully agree.
However this is a community project so I find statements like
"If you're touching a recipe at least make sure the creator/maintainer
agrees with your changes"
like happened in a recent commit somewhat against the open source policy.

And *if* we feel that creators/maintainers have a final say here, then
I'd suggest to list the name in the recipe.
Git log is only partially accurate due to the move from mtn to git and
the rename from packages to recipes.
>
>> And wrt the new staging/BBCLASSEXTEND/nativesdk topic:
>> In my opinion it is useful to clean up the existing recipes (or move
>> them to 'obsolete' or whatever).
>> That way less recipes need to be adopted, and no energy is wasted on
>> adopting legacy recipes.
>> (apart from the fact that having lots of recipes for lots of variants
>> does not really give a professional and mature impression).
>
> Legacy recipes are a source of contention. We're bad at tracking who
> needs them and why. There some some factions of OE who'd like to never
> see any recipe deleted and there are some who feel any old recipe should
> be removed.
>
> We do have a problem in that the people who use old recipes use them as
> they don't like change and the staging changes are change and hence we
> either don't convert them (and hence never complete the transition we
> *need* to make) or we convert them and cause those people pain anyway.
>
> I could see a case for having a mass clear out of old recipes in OE to
> get the new staging changes in. Anyone wanting old versions could either
> add them back specifically (converted), make sure they were converted by
> a deadline or use an older tree. Someone would have to take an effort
> like that on, announce it and lead it but I suspect it could actually be
> made to work. It will need some time commitment though, any
> volunteers? :)

I'm more than happy on converting some stuff.
And wrt the old recipes. Note that in the glib case I investigated
which ones were actually needed and proposed only to remove the ones
which were not used by any recipe or distro. (and ofc someone can have
a local overlay, then he/she takes a risk and probably should keep a
local copy and/or stick to a specific snapshot).

I am also all in favour of the suggestion from Otavio. The dev head
should use the latest version where possible. If you need stability
use the stable branch.
>
>> BTW: The recipes I feel responsible for are all converted to both new
>> staging and BBCLASSEXTEND.
>
> Great, thanks for doing that!
>
>> I have considered converting some of the others to new staging.
>> Actually I even started it, but soon stopped with it for the following
>> reasons:
>> - the actual verification process is fairly cumbersome. (5) diff the 2
>> packaged-staging recipes (which I read as packaged-staging packages as
>> there are no packaged-staging recipes) is imho a pita)
>
> It would be better to have some kind of automated way of doing this I
> agree. Its technically possible, just nobody has found the time needed
> to implement it. We're all volunteers as you point out.
>
>> - i have no idea what recipes are actually used and worthwhile my effort
>
> Ultimately its desirable to convert everything.

I beg to disagree. Converting legacy recipes seems pointless, and
converting recipes that are not touched for ages and that do not
appear in any image also might be less useful. But that is my opinion.
>
>> - some people seem to be picky if you touch their recipes (although
>> some are a lot less considerate when it comes to recipes of others :-(
>> )
>
> There are ways of handling this (RFC the patches, delay the commit for a
> few days. If no answer, then make the changes).

Agree (but on the other hand that makes it even more work).
I feel we should also have some mutual respect, and assume people do
things in good faith.
>
>> Together for me that has lead to the conclusion that this is work with
>> low satisfaction and high chance of getting negative feedback (e.g.
>> because despite your efforts something breaks, or because by accident
>> you step on someones toes), and that I'd better work on something
>> else.
>
> Well, we all feel like this at times. If I took all the negative stuff I
> see about my work to heart, I'd not be doing it. Hopefully people do
> feel some of the things I've done are some kind of benefit to OE. I have
> broken things before, I probably will again despite my best efforts but
> its how you deal with these things the people ultimately judge you on.
>
> I have yet to see a "thank you for helping set up the TSC, getting
> involved in the nastiest arguments OE has and putting your neck on the
> line all the time email" and don't expect one either. I doubt the e.V.
> board has either but for the record I do appreciate what they do and am
> trying to do my bit through the TSC.

Well then let me say a big thank you on what you did for OE.
It is indeed rarely said, but it is definitely appreciated!
>
>> PS: and wrt the remark "we have been discussed this before and the
>> conclusion then was...": great, but if you do not document those
>> decisions they will pop up every once in a while (e.g. by someone who
>> is not aware of the decision; e.g. I for me, was unaware that angstrom
>> initially had its own directory).
>
> Document where? How? Do you document the outcome of every email
> discussion you have on the OE list? It was a "decision" that came about
> as the result of an email discussion on this mailing list, nothing more,
> nothing less. Volunteers doing this would be very welcome...

I guess some of the things (like our way of working) could be
documented in the wiki.
And before you ask: sorry, no volunteer here. There are just too many
conflicting opinions outside & I feel I've opened enough cans of worms
recently.
>
> Cheers,
>
> Richard

Best regards, Frans

Re: TSC Meeting 2010/03/02

[Richard Purdie]

On Wed, 2010-03-03 at 15:28 +0100, Frans Meulenbroeks wrote:
> For the wording above I agree.
> The message in the pango thread, I felt as a snide remark directed
> directly to me (as I initiated the discussions).

I haven't looked at that thread so I'm not going to comment on that.

> I have not too much problems with the variable name as is.
> My intention was sincere and I felt that I was just following the procedure.
> Then someone started to claim that as author of the recipe he was not
> consulted and claimed he had the final say in it.
> Fine with me, but then please make clear what recipes you "own" and
> move them out of the common area.

Following the procedure includes listening to feedback and acting on it.
In the case I suspect we're talking about the commit was premature and a
consensus was not reached. If it had been the problems introduced by the
commit would not have happened. The revert then had its own issues. But
I'd suggest we call that one dealt with as I don't see what going over
it again will achieve.

"ownership" in OE is nowhere near as simple as you make out. There is a
file which lists areas which people take some responsibility for.

> I fully agree.
> However this is a community project so I find statements like
> "If you're touching a recipe at least make sure the creator/maintainer
> agrees with your changes"
> like happened in a recent commit somewhat against the open source policy.

No, its not. People have areas of expertise and areas they look
after/maintain. We all need to be considerate to that in our commits.
This is true of many open source projects.

> And *if* we feel that creators/maintainers have a final say here, then
> I'd suggest to list the name in the recipe.

We've done that before and it was a disaster after a while. The
maintainers file came into being instead.

> Git log is only partially accurate due to the move from mtn to git and
> the rename from packages to recipes.

By combining common sense, the output from git log (which can probably
be told to track renames) and the maintainers file, there is already
plenty of information out there.

> I am also all in favour of the suggestion from Otavio. The dev head
> should use the latest version where possible. If you need stability
> use the stable branch.

That is a decision for the distro ultimately but yes, I'd generally
agree.

> > Ultimately its desirable to convert everything.
> 
> I beg to disagree. Converting legacy recipes seems pointless, and
> converting recipes that are not touched for ages and that do not
> appear in any image also might be less useful. But that is my opinion.

Either convert or remove. My point is the end result of no legacy
staging.

> > There are ways of handling this (RFC the patches, delay the commit for a
> > few days. If no answer, then make the changes).
> 
> Agree (but on the other hand that makes it even more work).
> I feel we should also have some mutual respect, and assume people do
> things in good faith.

The whole commit policy relies on mutual respect and in general works
well. It just breaks down on some corner cases :(.

> > Document where? How? Do you document the outcome of every email
> > discussion you have on the OE list? It was a "decision" that came about
> > as the result of an email discussion on this mailing list, nothing more,
> > nothing less. Volunteers doing this would be very welcome...
> 
> I guess some of the things (like our way of working) could be
> documented in the wiki.
> And before you ask: sorry, no volunteer here. There are just too many
> conflicting opinions outside & I feel I've opened enough cans of worms
> recently.

There lies the problem. People have limited time and/or a limited amount
of patience in dealing with disagreements. The end result is compromise,
we do the best we can...

Cheers,

Richard

Re: TSC Meeting 2010/03/02

[Rolf Leggewie]

Richard, let me first express my gratitude for your efforts.

Richard Purdie wrote:
> Following the procedure includes listening to feedback and acting on it.
> In the case I suspect we're talking about the commit was premature and a
> consensus was not reached.

Sorry, disagree here.  Unless you define consensus as a unanimous
decision.  This POV is out there with some people, sometimes in the form
of "I feel free to veto and block just about anything, but I will gladly
override negative feedback for my own commits".  I don't share the "You
have to have a unanimous decision" POV especially if the veto is IMHO
obviously out there for the sole reason to stall changes indefinitely
(and keep the breakage for others, which it seems some people would like
to spin as Angstrom-hunting, which is of course, bull).  Let's also not
forget, this was a non-core change and did not even need an RFC.

I strongly object to the notion that the feedback given until the commit
in question wasn't taken into account.  I feel it's quite a stunt to
even suggest otherwise, especially since there's ample and public
evidence to the contrary.  I'm not saying that suggestions made *after*
the commit couldn't and shouldn't have improved on the solution (instead
of reverting).

I do agree with Frans that there are still very many fuzzy areas as to
what is permittable in OE and what not.  I also agree with Frans that
it's becoming increasingly difficult to "move OE forward", whatever that
means for the individual.  And yes, I see the conflict between fixing
those two things.  Both effects greatly decrease the fun to hack on OE,
though, and has given OE a very slerotic feeling on my end lately.  I
fully understand Frans' feeling of "whatever you do in OE, you'll likely
get burned".

Frans, I hope I did not paraphrase your sentiments incorrectly.  Feel
free to correct me if I did.

Re: TSC Meeting 2010/03/02

[Frans Meulenbroeks]

2010/3/5 Rolf Leggewie <no2spam@nospam.arcornews.de>:

[...]
>
> Frans, I hope I did not paraphrase your sentiments incorrectly.  Feel
> free to correct me if I did.

You didn't :-)

I've indeed come to the conclusion that apparently OE has come to a
point where it is very hard to move forward.
One of the reasons is the perception of quality for some people.

Quality to me does not mean having 26 glib recipes around or 8 abiword
ones or whatever most of which are likely to be unused and even more
likely to be unmaintained.
We currently have close to 9000 recipes, 3000+of which are older versions.
I understand why people feel they should keep old versions, but that
is where a version control system is for.

Development head should reflect the latest state-of-the-art, and
probably should have only one version per recipe.
(probably with the exception of things like gcc, linux and u-boot).
If things do not work with a version, they should be fixed. Keeping
the old version around and pin it, means that in the end you end up
with a system which is lagging behind.

If you want stability use a stable branch. head should focus on moving forward.

Some people seem to think differently about it. As an alternative an
obsolete directory has been proposed.
The latter does not really help. It gives the crud a home, but it does
not really solve the problem.

However as discussions on what to remove are time consuming and
progress is hard, I have abandoned that path.

Instead I decided to create a branch called sanity (for now local, but
once it is more reliable I'll probably push it)
In this branch I intend to
- remove all old versions of recipes (sometimes tough as there are
recipes that have both numbered and cvs/svn/git variants (I believe
there is a case where there is even cvs and svn for package))
  exceptions: gcc (but some versions will go there), linux, u-boot)
- crude convert to BBCLASSEXTEND="native". I feel this should in
general work. (btw and I noticed we have packaged that do have native
variants for older versions but not for the recent one, and I have
even seen a case where the native recipe is newer than the target
one).
Plan was also to remove all do_deploy stuff, but apart from
u-boot/linux this is nearly done.

Note that the above edits may sound harsh, but frankly I doubt that
anyone will ever convert those 3000 legacy devices, and even if they
are converted, I strongly doubt that they are tested.
This seems to be a better way forward.

After that I have some ideas for further improvements, but let's get
this started first.

If anyone wants to work with me on this, feel free to get in touch with me.
And for those who feel that effort should be directed elsewhere. Make
me an interesting offer and we can talk. But until that it are my
weekends and evenings I am spending on this, and I'll spend them as I
see fit, not as someone else sees fit (ok, with the exception of the
Mrs :-) )

Have fun!
Frans