On Thu, Jan 21, 2010 at 11:52 PM, Frans Meulenbroeks <[email protected]> wrote: > 2010/1/21 Phil Blundell <[email protected]>: >> 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 >> [email protected] >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >> > > _______________________________________________ > Openembedded-devel mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
