TSC Meetings for the meeting of may

TSC Meetings for the meeting of may

[Holger Freyther]

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

Re: TSC Meetings for the meeting of may

[Khem Raj]

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

Re: TSC Meetings for the meeting of may

[Tom Rini]

Khem Raj wrote:
> On (20/05/10 05:16), Holger Freyther wrote:
[snip]
>> 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.

In general, I think this will be OK.  But the compat with __ external 
distro cases (both say old compat things or as just an example, Android 
1.x uses gcc 4.2.1 iirc as the libgcc exception was still WIP for GPLv3) 
are the exception.

-- 
Tom Rini
Mentor Graphics Corporation

Re: TSC Meetings for the meeting of may

[Khem Raj]

On Wed, May 19, 2010 at 6:23 PM, Tom Rini <tom_rini@mentor.com> wrote:
> Khem Raj wrote:
>>
>> On (20/05/10 05:16), Holger Freyther wrote:
>
> [snip]
>>>
>>> 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.
>
> In general, I think this will be OK.  But the compat with __ external distro
> cases (both say old compat things or as just an example, Android 1.x uses
> gcc 4.2.1 iirc as the libgcc exception was still WIP for GPLv3) are the
> exception.

hmm yeah the license change is a given case. We have to keep 4.2.1
around because it was
 as we all know last GPLv2 release. The runtime exceptions based on
GPLv3 were not placed
until January of 2009, they were under GPLv2 runtime exception until then.

>
> --
> Tom Rini
> Mentor Graphics Corporation
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>