Am Donnerstag, den 07.01.2010, 20:26 +0000 schrieb Phil Blundell: > On Thu, 2010-01-07 at 20:48 +0100, Leon Woestenberg wrote: > > What should that responsibility involve? > > > > I usually "test" on one or two machines but still set a DEFAULT_PREFERENCE > > "-1". > > > > It's very hard for the committer to collect enough testing evidence > > for all the use cases / variables. > > It seems fairly clear that no individual committer is going to be able > to test all the possible permutations for even moderately complicated > packages. If we require exhaustive testing before anything can land in > the tree then development will just grind to a halt. And, as I > mentioned in my previous email, the primary responsibility for > integration lies with the DISTRO maintainers, who can use tools like > PREFERRED_VERSION to limit the amount of unexpected churn in their > configurations. > > It's probably a job for the TSC to come up with a definitive policy in > this area. But, for myself, I would consider someone checking in a new > version to have discharged their duties in a responsible manner if: > > - the new version has the same, or at least an equivalent, default > configuration as the old one (i.e. no gratuitous changes to EXTRA_OECONF > or the like); and > > - all the patches that were applied to the old version are either still > applied to the new version, or have been established to be unnecessary; > and > > - the new package has been successfully compiled, and ideally tested, > in at least one configuration; and > > - once we have a functioning waterfall view in tinderbox, the checkin > doesn't cause any of our primary MACHINE/DISTRO combinations to burst > into flames > > I guess the key thing is not to make committers feel that they will be > held to account for things that are outside their realistic control > (i.e. bugs that have been introduced upstream in the new version), while > still expecting them to take reasonable steps to avoid introducing > unnecessary breakage. > > Automatically adding new versions with a negative DEFAULT_PREFERENCE > doesn't scale: if everybody did this then, eventually, we would end up > with virtually the whole tree being D_P -1. And it sends a confusing > message to other users, since people tend to assume that a recipe with a > negative D_P is broken or harmful in some way rather than merely > untested or untrusted. I would also propose that, in future, any > setting of DEFAULT_PREFERENCE in a recipe must be accompanied by a > comment explaining why it was set, and (if it is set negatively) under > what conditions it can or should be removed.
Agreed, I think that's a sensible way to deal with it. :M: _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
