All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rolf Leggewie <no2spam@nospam.arcornews.de>
To: openembedded-devel@lists.openembedded.org
Subject: Re: TSC Meeting 2010/03/02
Date: Fri, 05 Mar 2010 18:47:49 +0100	[thread overview]
Message-ID: <hmrg46$6m7$1@dough.gmane.org> (raw)
In-Reply-To: <1267629590.2259.92.camel@rex>

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.




  reply	other threads:[~2010-03-05 17:51 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
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 [this message]
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='hmrg46$6m7$1@dough.gmane.org' \
    --to=no2spam@nospam.arcornews.de \
    --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.