Re: RFC: Bump default version for gtk+ to 2.18.3

[Michael 'Mickey' Lauer <mickey@vanille-media.de>]

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: