Re: TSC Meetings for the meeting of may

[Khem Raj <raj.khem@gmail.com>]

On (20/05/10 05:16), Holger Freyther wrote:
> Hi,
> 
> sorry for the delay of finishing up the minutes, it is late at night so
> I am sure I have messed up something in one way or another... take care.
> 
> 
> TSC Meeting 2010/05/06
> 
> Where to hold meetings
> ======================
> The TSC decided to hold future meetings on IRC as every member
> of the TSC already have irc clients installed and the same was
> not true for jabber clients.
> 
> Make packaged-staging mandatory
> ===============================

fine

> The TSC decided to make packaged-staging mandatory as this will
> allow further simplification of the classes, gives additional
> features. The TSC is aware that there are still recipes left to
> migrate away from the legacy staging and that building these will
> increase the build time right now.
> 
> Make insane mandatory
> =====================

fine

> The TSC believes that the insane.bbclass contributes to making
> builds more reliable and point out errors early on. On the other
> hand the TSC is aware that these checks might get into the way
> during rapid prototyping. The TSC believes the right balance is
> to enable the insane.bbclass by default but to change the default
> to warn instead of failing the build and existing users will be
> able to opt for fatal errors instead of warnings.
> 
> 
> Removing old versions
> =====================
> The TSC looked into the topic of when to remove versions.
> 
> 
> The TSC thinks there can not be a general rule of when to delete
> a package. The TSC believes that in some cases a package should
> never be deleted, e.g. with GCC/GLIBC to target a specific device
> or distribution. For a series of major releases it seems plausible
> to only keep the latest minor release of each release series around
> given that the quality should increase with each minor release but
> a removal of a minor release should not be done if there is a
> PREFERRED_VERSION set. The TSC believes that 24 months can be a good
> time to remove old major releases but it is certainly not the only
> criteria for a removal.

gcc makes minor releases and in general they are bug fix only releases.
like kernel.

I would propose that OE count such packages with major release only.
e.g. gcc 4.4 (indicated 4.4.x) 4.5 and so on. This will simplify the
maintenance and reduce duplication, with one downside that if some DISTRO does not need a 
bug fix that was say done in 4.4.4 and is currently using 4.4.3 as
preferred cross compiler. Although chances of such cases will be low.


Thanks
-Khem