RFC: Bump default version for gtk+ to 2.18.3

RFC: Bump default version for gtk+ to 2.18.3

[Rolf Leggewie]

Hi,

as evidenced by http://tinderbox.openembedded.org/packages/407335/ the
current default gtkmm (2.18.1) does not compile with the current default
gtk+ (2.14.2).  My suggestion is to remove DEFAULT_PREFERENCE -1 from
the 2.18.3 recipe and make it the new OE default.

Objections?

Regards

Rolf

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

[Phil Blundell]

On Thu, 2010-01-07 at 20:03 +0100, Rolf Leggewie wrote:
> as evidenced by http://tinderbox.openembedded.org/packages/407335/ the
> current default gtkmm (2.18.1) does not compile with the current default
> gtk+ (2.14.2).  My suggestion is to remove DEFAULT_PREFERENCE -1 from
> the 2.18.3 recipe and make it the new OE default.

Assuming that 2.18.3 compiles and doesn't have any glaring defects then
that sounds like a fine plan.  DEFAULT_PREFERENCE is, frankly, rather
too blunt an instrument to be of much use nowadays: any DISTROs that
particularly wish to use 2.14.2 should be (and probably are) setting it
as their PREFERRED_VERSION.

All too often we end up with new versions being stuck in at
DEFAULT_PREFERENCE -1 simply because the person updating the recipe
didn't want to take the responsibility for testing it.  This is
something of an unsatisfactory situation and maybe one that the TSC
could address in due course with some kind of policy formulation.

p.

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

[Leon Woestenberg]

Hello,

On Thu, Jan 7, 2010 at 8:22 PM, Phil Blundell <philb@gnu.org> wrote:
>
> All too often we end up with new versions being stuck in at
> DEFAULT_PREFERENCE -1 simply because the person updating the recipe
> didn't want to take the responsibility for testing it.  This is
>
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.

Maybe we should be less restrictive on bug fix releases (typically
x.y.z to x.y.z+small number).

Regards,
-- 
Leon

Re: 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.

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

[Leon Woestenberg]

Hello,

thanks for the valuable insights.

On Thu, Jan 7, 2010 at 9:26 PM, Phil Blundell <philb@gnu.org> wrote:
>
> 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.
>

I would propose that anything out-of-the ordinary in a recipe is accompanied
with a comment.

I.e. if there is a reason outside OpenEmbedded for disabling or working around
something, please mention it in the recipe.


Regards,
-- 
Leon

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

[Michael 'Mickey' Lauer]

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:

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

[Martyn Welch]

Phil Blundell wrote:
> 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.
>

I've recently had a small problem related to this. All of the kernel
packages seem to have DEFAULT_PREFERENCE=-1, for popular targets this
isn't a problem, but for less popular ones it was picking the latest
kernel at D_P=-1. Oddly this failed to build for "x86".

I'd suggest it would be sensible to remove all (or most)
"DEFAULT_PREFERENCE=-1" instances and only use
"DEFAULT_PREFERENCE-<target>=x" it to increase the preference for
specific targets, or leave it entirely up to the distributions.

Martyn


-- 
Martyn Welch (Principal Software Engineer)   |   Registered in England and
GE Intelligent Platforms                     |   Wales (3828642) at 100
T +44(0)127322748                            |   Barbirolli Square,
Manchester,
E martyn.welch@gefanuc.com                   |   M2 3AB  VAT:GB 927559189

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

[Marcin Juszkiewicz]

Dnia piątek, 8 stycznia 2010 o 10:36:01 Martyn Welch napisał(a):

> I've recently had a small problem related to this. All of the kernel
> packages seem to have DEFAULT_PREFERENCE=-1, for popular targets this
> isn't a problem, but for less popular ones it was picking the latest
> kernel at D_P=-1. Oddly this failed to build for "x86".
 
> I'd suggest it would be sensible to remove all (or most)
> "DEFAULT_PREFERENCE=-1" instances and only use
> "DEFAULT_PREFERENCE-<target>=x" it to increase the preference for
> specific targets, or leave it entirely up to the distributions.

For kernels I would ack it. If device is supported by one version then it has 
D_P_machinename = "1" set usually. Some of targets are fine with newer 
versions out-of-box.

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz