[oe] RFC: Bump default version for gtk+ to 2.18.3

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

p.