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. p. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
