[oe] include default PR or not (was: [PATCH] barebox: Add recipe for this new bootloader)

Phil Blundell philb at gnu.org
Thu Jan 21 22:53:34 UTC 2010


On Mon, 2010-01-18 at 17:24 +0100, Rolf Leggewie wrote:
> Richard Purdie wrote:
> > On Mon, 2010-01-18 at 13:10 +0000, Phil Blundell wrote:
> [...]
> >> only way we will get a definitive answer would be to have the TSC hand
> >> down a judgement on the matter.
> > 
> > That would seem sensible if only to lay this matter to rest once and for
> > all! It would also be good to test the TSC processes...
> 
> I would think this is too minor for the TSC to bother.  But if you want
> to take it on, why should I object?  It does take up bandwidth on this
> list from time to time, so much is true.  Personally, I don't think the
> best option would be to rule in favor of one or the other faction,
> because that's what it would be seen for.  I don't think the TSC can
> really win and resolve this issue.

I'm not entirely sure what point you are making about it being
undesirable for the TSC to "rule in favour of one or the other faction".
One of the primary roles of the TSC is to resolve or adjudicate disputes
between developers and, since such disputes are often binary issues by
their nature, it seems likely that in a lot of cases this is going to
boil down to having the TSC accept the viewpoint of one party and reject
the viewpoint of the other.  It would certainly be a shame for the TSC
to shy away from making a decision just because it might be seen to
agree with one group and disagree with another.

A large part of the reason for having the TSC in the first place was to
establish a group of people who were empowered (and, indeed, obliged) to
make decisions, and I think this is a fairly good example of a situation
where simply having a decision of some kind is more important than the
detail of what exactly that decision is.  

This particular issue is clearly somewhat trivial and, whichever
viewpoint prevails, the impact in the real world is going to be fairly
small.  But it has cropped up on this list several times now and it
seems equally clear that, so long as it remains unresolved, it will
continue to waste everybody's time and contributors will continue to be
baffled as to what exactly they should put in their patches in order to
get them applied.

p.






More information about the Openembedded-devel mailing list