All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: TSC Meeting 2010/03/02
Date: Wed, 3 Mar 2010 13:59:19 +0100	[thread overview]
Message-ID: <ac9c93b11003030459h499fa3ban6f6884910ef785a@mail.gmail.com> (raw)
In-Reply-To: <1267616149.2259.4.camel@rex>

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).



  reply	other threads:[~2010-03-03 13:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-03 11:35 TSC Meeting 2010/03/02 Richard Purdie
2010-03-03 12:59 ` Frans Meulenbroeks [this message]
2010-03-03 13:26   ` Marcin Juszkiewicz
2010-03-03 13:47   ` Richard Purdie
2010-03-03 14:04     ` Martin Jansa
2010-03-03 14:28     ` Frans Meulenbroeks
2010-03-03 15:19       ` Richard Purdie
2010-03-05 17:47         ` Rolf Leggewie
2010-03-06 12:25           ` Frans Meulenbroeks

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=ac9c93b11003030459h499fa3ban6f6884910ef785a@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.