[oe] TSC Meeting 2010/03/02

Frans Meulenbroeks fransmeulenbroeks at gmail.com
Wed Mar 3 12:59:19 UTC 2010


Richard, thanks for the report.

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

2010/3/3 Richard Purdie <rpurdie at 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).




More information about the Openembedded-devel mailing list