[oe] RFC: Bump default version for gtk+ to 2.18.3
Michael 'Mickey' Lauer
mickey at vanille-media.de
Fri Jan 8 00:34:31 UTC 2010
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:
More information about the Openembedded-devel
mailing list