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