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

[Khem Raj]

On Thu, Jan 21, 2010 at 11:52 PM, Frans Meulenbroeks
<fransmeulenbroeks at gmail.com> wrote:
> 2010/1/21 Phil Blundell <philb at gnu.org>:
>> 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.
>
> Actually the # of options for TSC are somewhat bigger.
> A decision could be that X is the required way of working and !X is not ok
> However, it can also be weakened into making X is the preferred way
> and !X less desirable (without forbidding it)
> And there is still the option to leave X as a personal preference to
> the developer.
>
> For PR, guess my suggestion would be to have PR="r0" as preferred and
> not having PR as less desirabe.
> But if you make a change bumping PR (or adding PR="r1", if no PR
> exists) is required.

IMO Letting PR=r0 is better because it does help people in remembering
to bump PR when they make the first change after r0
afterall 0 is also a number so it does convey some information in the recipe.

>
> Frans
>>
>> 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.
>>
>>
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>