RFC: new stable release

RFC: new stable release

[Marcin Juszkiewicz]

[-- Attachment #1: Type: text/plain, Size: 2548 bytes --]


Hi

I know that there were lot of talks about creating stable branch of 
OpenEmbedded in last months. But we need stable branch for vendors which 
use our product.

As some people know I am working for Bug Labs company. Their product 
named 'BUG Linux' is based on Poky 'pinky' (last stable release). We 
were considering switch to newer (but never released) version named 
'elroy' but recently we decided to switch to OpenEmbedded. 

But to what kind of OE? Development branch change every day and things 
break from time to time, packages get version bumps without notifying 
anyone etc. Other possibility would be switch to stable branch but 
current one is deprecated and not maintained anymore.

So the situation looks like we will need new stable branch with few 
maintainers (I will be one of them) and with proper policies for merging 
updates from development tree of OE. I maintained OE branches used for 
OpenZaurus/Familiar few years ago so can say that I have needed 
experience for it.

Which things needs defining? I have few in mind:

1. Adding new things. This should be possible only by backporting from
   OE.dev tree and needs to be Acked by at least 2-3 developers which
   use stable branch. New code has to build for at least one distro and
   ARM+x86 architectures (unless it is related to one arch or even one 
   machine).

2. Marking recipes as buildable or not. With over 6000 of them it is
   really hard to check everything for status. We can remove many old
   versions but sometimes they are useful for some projects. I would   
   rather add things like BUILDABLE_armv4t = "1" into recipe or into
   conf/distro/include/${DISTRO}-status.inc file. Similar status for
   recipes which are known to not work for some archs.

3. Dealing with non buildable stuff. We have 'nonworking' and 'obsolete' 
   dirs in metadata - both should be dropped in stable branch. Other
   recipes can be marked as not buildable or dropped from branch - I did
   not thought yet on it.

4. Lifetime of branch. Will we do new stable release after 6 months or
   after one year? For how long stable branch will be supported by OE
   itself? I know that there will be companies which will provide
   support for longer time - thats what I do with Poky 'pinky' now.

What do you feel about it? Any opinions or suggestions? Want to join 
effort?

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 204 bytes --]

Re: RFC: new stable release

[Koen Kooi]

On 17-03-09 15:38, Marcin Juszkiewicz wrote:

> Which things needs defining? I have few in mind:
>
> 1. Adding new things. This should be possible only by backporting from
>     OE.dev tree and needs to be Acked by at least 2-3 developers which
>     use stable branch. New code has to build for at least one distro and
>     ARM+x86 architectures (unless it is related to one arch or even one
>     machine).

So things must get tested before committing, right?

> 2. Marking recipes as buildable or not. With over 6000 of them it is
>     really hard to check everything for status. We can remove many old
>     versions but sometimes they are useful for some projects. I would
>     rather add things like BUILDABLE_armv4t = "1" into recipe or into
>     conf/distro/include/${DISTRO}-status.inc file. Similar status for
>     recipes which are known to not work for some archs.

Just have a CSV file that includes the test coverage for package + 
machines. We can have one per distro. If needed we can extract the info 
from tinderbox after we've done a few builds.

> 3. Dealing with non buildable stuff. We have 'nonworking' and 'obsolete'
>     dirs in metadata - both should be dropped in stable branch. Other
>     recipes can be marked as not buildable or dropped from branch - I did
>     not thought yet on it.

That does mean you can't easily resurrect recipes, but seeing that only 
happens once every 5 years or so..

> 4. Lifetime of branch. Will we do new stable release after 6 months or
>     after one year? For how long stable branch will be supported by OE
>     itself? I know that there will be companies which will provide
>     support for longer time - thats what I do with Poky 'pinky' now.

The previous branch had a 12 + 3 month lifecycle, 12 months of support 
then 3 months to wind down.

> What do you feel about it? Any opinions or suggestions? Want to join
> effort?

I certainly want to join the effort, but I fear that creating a stable 
branch might make some people more inclined to dump even worse crap in 
.dev, which would not be a good thing. So *if* we go with a stable 
branch we should make sure .dev well be in a good shape as well.

regards,

Koen

Re: RFC: new stable release

[Marco Cavallini]

Marcin Juszkiewicz ha scritto:
> Hi
> 
> I know that there were lot of talks about creating stable branch of 
> OpenEmbedded in last months. But we need stable branch for vendors which 
> use our product.
> 
> As some people know I am working for Bug Labs company. Their product 
> named 'BUG Linux' is based on Poky 'pinky' (last stable release). We 
> were considering switch to newer (but never released) version named 
> 'elroy' but recently we decided to switch to OpenEmbedded. 
> 
> But to what kind of OE? Development branch change every day and things 
> break from time to time, packages get version bumps without notifying 
> anyone etc. Other possibility would be switch to stable branch but 
> current one is deprecated and not maintained anymore.
> 
> So the situation looks like we will need new stable branch with few 
> maintainers (I will be one of them) and with proper policies for merging 
> updates from development tree of OE. I maintained OE branches used for 
> OpenZaurus/Familiar few years ago so can say that I have needed 
> experience for it.
> 
> Which things needs defining? I have few in mind:
> 
> 1. Adding new things. This should be possible only by backporting from
>    OE.dev tree and needs to be Acked by at least 2-3 developers which
>    use stable branch. New code has to build for at least one distro and
>    ARM+x86 architectures (unless it is related to one arch or even one 
>    machine).
> 
> 2. Marking recipes as buildable or not. With over 6000 of them it is
>    really hard to check everything for status. We can remove many old
>    versions but sometimes they are useful for some projects. I would   
>    rather add things like BUILDABLE_armv4t = "1" into recipe or into
>    conf/distro/include/${DISTRO}-status.inc file. Similar status for
>    recipes which are known to not work for some archs.
> 
> 3. Dealing with non buildable stuff. We have 'nonworking' and 'obsolete' 
>    dirs in metadata - both should be dropped in stable branch. Other
>    recipes can be marked as not buildable or dropped from branch - I did
>    not thought yet on it.
> 
> 4. Lifetime of branch. Will we do new stable release after 6 months or
>    after one year? For how long stable branch will be supported by OE
>    itself? I know that there will be companies which will provide
>    support for longer time - thats what I do with Poky 'pinky' now.
> 
> What do you feel about it? Any opinions or suggestions? Want to join 
> effort?

I think that a stable branch is defintely necessary when you are using
OE in industrial environment like we do. A Long Term support would be
good as well for dome main branches, something like Ubuntu does.
I agree with this proposal.

Cordiali Saluti / Kindest Regards / mit freundlichen Grüssen
--
Marco Cavallini | KOAN sas | Bergamo - Italia
 embedded and real-time software engineering
   Atmel third party certified consultant
Phone:+39-035-255.235 - Fax:+39-178-22.39.748
      http://www.KoanSoftware.com

Re: RFC: new stable release

[Matteo Fortini]

Just my 2c:
this definitely needs to be done not to shy away "professional" people 
who want to try OE: I personally tried angstrom + qpe with Angstrom on 
x86 and I got lots of problems straight from the beginning.

I mean that it'd be better to have only 3 images which are know to work, 
and all the rest which refuse to build, rather than show off that we can 
do this and that, and everything one tries resulting being broken.

Regards,
Matteo

Marcin Juszkiewicz ha scritto:
> Hi
>
> I know that there were lot of talks about creating stable branch of 
> OpenEmbedded in last months. But we need stable branch for vendors which 
> use our product.
>
> As some people know I am working for Bug Labs company. Their product 
> named 'BUG Linux' is based on Poky 'pinky' (last stable release). We 
> were considering switch to newer (but never released) version named 
> 'elroy' but recently we decided to switch to OpenEmbedded. 
>
> But to what kind of OE? Development branch change every day and things 
> break from time to time, packages get version bumps without notifying 
> anyone etc. Other possibility would be switch to stable branch but 
> current one is deprecated and not maintained anymore.
>
> So the situation looks like we will need new stable branch with few 
> maintainers (I will be one of them) and with proper policies for merging 
> updates from development tree of OE. I maintained OE branches used for 
> OpenZaurus/Familiar few years ago so can say that I have needed 
> experience for it.
>
> Which things needs defining? I have few in mind:
>
> 1. Adding new things. This should be possible only by backporting from
>    OE.dev tree and needs to be Acked by at least 2-3 developers which
>    use stable branch. New code has to build for at least one distro and
>    ARM+x86 architectures (unless it is related to one arch or even one 
>    machine).
>
> 2. Marking recipes as buildable or not. With over 6000 of them it is
>    really hard to check everything for status. We can remove many old
>    versions but sometimes they are useful for some projects. I would   
>    rather add things like BUILDABLE_armv4t = "1" into recipe or into
>    conf/distro/include/${DISTRO}-status.inc file. Similar status for
>    recipes which are known to not work for some archs.
>
> 3. Dealing with non buildable stuff. We have 'nonworking' and 'obsolete' 
>    dirs in metadata - both should be dropped in stable branch. Other
>    recipes can be marked as not buildable or dropped from branch - I did
>    not thought yet on it.
>
> 4. Lifetime of branch. Will we do new stable release after 6 months or
>    after one year? For how long stable branch will be supported by OE
>    itself? I know that there will be companies which will provide
>    support for longer time - thats what I do with Poky 'pinky' now.
>
> What do you feel about it? Any opinions or suggestions? Want to join 
> effort?
>
> Regards, 
>   

Re: RFC: new stable release

[Mathieu Chouinard]

On Tue, Mar 17, 2009 at 10:50 AM, Koen Kooi <k.kooi@student.utwente.nl>wrote:

> On 17-03-09 15:38, Marcin Juszkiewicz wrote:
>
>  Which things needs defining? I have few in mind:
>>
>> 1. Adding new things. This should be possible only by backporting from
>>    OE.dev tree and needs to be Acked by at least 2-3 developers which
>>    use stable branch. New code has to build for at least one distro and
>>    ARM+x86 architectures (unless it is related to one arch or even one
>>    machine).
>>
>
> So things must get tested before committing, right?
>
>  2. Marking recipes as buildable or not. With over 6000 of them it is
>>    really hard to check everything for status. We can remove many old
>>    versions but sometimes they are useful for some projects. I would
>>    rather add things like BUILDABLE_armv4t = "1" into recipe or into
>>    conf/distro/include/${DISTRO}-status.inc file. Similar status for
>>    recipes which are known to not work for some archs.
>>
>
> Just have a CSV file that includes the test coverage for package +
> machines. We can have one per distro. If needed we can extract the info from
> tinderbox after we've done a few builds.
>
>  3. Dealing with non buildable stuff. We have 'nonworking' and 'obsolete'
>>    dirs in metadata - both should be dropped in stable branch. Other
>>    recipes can be marked as not buildable or dropped from branch - I did
>>    not thought yet on it.
>>
>
> That does mean you can't easily resurrect recipes, but seeing that only
> happens once every 5 years or so..
>
>  4. Lifetime of branch. Will we do new stable release after 6 months or
>>    after one year? For how long stable branch will be supported by OE
>>    itself? I know that there will be companies which will provide
>>    support for longer time - thats what I do with Poky 'pinky' now.
>>
>
> The previous branch had a 12 + 3 month lifecycle, 12 months of support then
> 3 months to wind down.
>
>  What do you feel about it? Any opinions or suggestions? Want to join
>> effort?
>>
>
> I certainly want to join the effort, but I fear that creating a stable
> branch might make some people more inclined to dump even worse crap in .dev,
> which would not be a good thing. So *if* we go with a stable branch we
> should make sure .dev well be in a good shape as well.
>
> regards,
>
> Koen
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailmanM<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel>


Simply create a .exp branch for this
Mathieu
-- 
there is an old Greek saying that goes like this:
“There are two kinds of people in this world that
go around beardless—boys and women—and I am neither one.”

Re: RFC: new stable release

[Marcin Juszkiewicz]

Dnia wtorek, 17 marca 2009 o 15:50:43 Koen Kooi napisał(a):
> On 17-03-09 15:38, Marcin Juszkiewicz wrote:
> > Which things needs defining? I have few in mind:
> >
> > 1. Adding new things. This should be possible only by backporting
> > from OE.dev tree and needs to be Acked by at least 2-3 developers
> > which use stable branch. New code has to build for at least one
> > distro and ARM+x86 architectures (unless it is related to one arch
> > or even one machine).
>
> So things must get tested before committing, right?

Yes. If change which was tested only on ARM I can run test for x86 but 
this will enlarge review time.

> > 2. Marking recipes as buildable or not. With over 6000 of them it
> > is really hard to check everything for status. We can remove many
> > old versions but sometimes they are useful for some projects. I
> > would rather add things like BUILDABLE_armv4t = "1" into recipe or
> > into conf/distro/include/${DISTRO}-status.inc file. Similar status
> > for recipes which are known to not work for some archs.
>
> Just have a CSV file that includes the test coverage for package +
> machines. We can have one per distro. If needed we can extract the
> info from tinderbox after we've done a few builds.

The CSV file is ok for me too - small script added into contrib/ would 
show this data in more handy way.

> > 3. Dealing with non buildable stuff. We have 'nonworking' and
> > 'obsolete' dirs in metadata - both should be dropped in stable
> > branch. Other recipes can be marked as not buildable or dropped
> > from branch - I did not thought yet on it.
>
> That does mean you can't easily resurrect recipes, but seeing that
> only happens once every 5 years or so..

"All changes has to exists in .dev tree" so if someone will fix broken 
recipe then change will land in .dev first probably... Unless there is 
no same version in .dev anymore.

> > 4. Lifetime of branch. Will we do new stable release after 6 months
> > or after one year? For how long stable branch will be supported by
> > OE itself? I know that there will be companies which will provide
> > support for longer time - thats what I do with Poky 'pinky' now.
>
> The previous branch had a 12 + 3 month lifecycle, 12 months of
> support then 3 months to wind down.

1 year sounds good. Poky 'pinky' is about 1 year old and still usable.

> I certainly want to join the effort, but I fear that creating a
> stable branch might make some people more inclined to dump even worse
> crap in .dev, which would not be a good thing. So *if* we go with a
> stable branch we should make sure .dev well be in a good shape as
> well.

There always will be good and bad things with .dev branch. We can look 
to adapt some rules from stable to .dev later. Larger changes can go 
through separate branches.

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

Re: RFC: new stable release

[Mike (mwester)]

Marcin Juszkiewicz wrote:
> Hi
> 
> I know that there were lot of talks about creating stable branch of 
> OpenEmbedded in last months. But we need stable branch for vendors which 
> use our product.
> 
> As some people know I am working for Bug Labs company. Their product 
> named 'BUG Linux' is based on Poky 'pinky' (last stable release). We 
> were considering switch to newer (but never released) version named 
> 'elroy' but recently we decided to switch to OpenEmbedded. 
> 
> But to what kind of OE? Development branch change every day and things 
> break from time to time, packages get version bumps without notifying 
> anyone etc. Other possibility would be switch to stable branch but 
> current one is deprecated and not maintained anymore.
> 
> So the situation looks like we will need new stable branch with few 
> maintainers (I will be one of them) and with proper policies for merging 
> updates from development tree of OE. I maintained OE branches used for 
> OpenZaurus/Familiar few years ago so can say that I have needed 
> experience for it.
> 
> Which things needs defining? I have few in mind:
> 
> 1. Adding new things. This should be possible only by backporting from
>    OE.dev tree and needs to be Acked by at least 2-3 developers which
>    use stable branch. New code has to build for at least one distro and
>    ARM+x86 architectures (unless it is related to one arch or even one 
>    machine).
> 
> 2. Marking recipes as buildable or not. With over 6000 of them it is
>    really hard to check everything for status. We can remove many old
>    versions but sometimes they are useful for some projects. I would   
>    rather add things like BUILDABLE_armv4t = "1" into recipe or into
>    conf/distro/include/${DISTRO}-status.inc file. Similar status for
>    recipes which are known to not work for some archs.
> 
> 3. Dealing with non buildable stuff. We have 'nonworking' and 'obsolete' 
>    dirs in metadata - both should be dropped in stable branch. Other
>    recipes can be marked as not buildable or dropped from branch - I did
>    not thought yet on it.
> 
> 4. Lifetime of branch. Will we do new stable release after 6 months or
>    after one year? For how long stable branch will be supported by OE
>    itself? I know that there will be companies which will provide
>    support for longer time - thats what I do with Poky 'pinky' now.
> 
> What do you feel about it? Any opinions or suggestions? Want to join 
> effort?

+1 from me.

I'd also suggest that it might be helpful if we could define one or a
few "reference host configurations".  On this side of the pond, for
commercial work that would be RHEL4 or RHEL5.  I'll volunteer to set up
such a reference host, and document the necessary packages/patches
required to build the stable branch on that platform.


-Mike (mwester)

Re: RFC: new stable release

[Richard Purdie]

On Tue, 2009-03-17 at 15:38 +0100, Marcin Juszkiewicz wrote:
> I know that there were lot of talks about creating stable branch of 
> OpenEmbedded in last months. But we need stable branch for vendors which 
> use our product.
> 
> As some people know I am working for Bug Labs company. Their product 
> named 'BUG Linux' is based on Poky 'pinky' (last stable release). We 
> were considering switch to newer (but never released) version named 
> 'elroy' but recently we decided to switch to OpenEmbedded.

I'm sorry to hear that :(.

I'm still trying to find time to make that elroy release but fate keeps
conspiring against me :/.

Cheers,

Richard

Re: RFC: new stable release

[Tom Rini]

On Tue, Mar 17, 2009 at 10:25:59AM -0500, Mike (mwester) wrote:
> Marcin Juszkiewicz wrote:
> > Hi
> > 
> > I know that there were lot of talks about creating stable branch of 
> > OpenEmbedded in last months. But we need stable branch for vendors which 
> > use our product.
> > 
> > As some people know I am working for Bug Labs company. Their product 
> > named 'BUG Linux' is based on Poky 'pinky' (last stable release). We 
> > were considering switch to newer (but never released) version named 
> > 'elroy' but recently we decided to switch to OpenEmbedded. 
> > 
> > But to what kind of OE? Development branch change every day and things 
> > break from time to time, packages get version bumps without notifying 
> > anyone etc. Other possibility would be switch to stable branch but 
> > current one is deprecated and not maintained anymore.
> > 
> > So the situation looks like we will need new stable branch with few 
> > maintainers (I will be one of them) and with proper policies for merging 
> > updates from development tree of OE. I maintained OE branches used for 
> > OpenZaurus/Familiar few years ago so can say that I have needed 
> > experience for it.
> > 
> > Which things needs defining? I have few in mind:
> > 
> > 1. Adding new things. This should be possible only by backporting from
> >    OE.dev tree and needs to be Acked by at least 2-3 developers which
> >    use stable branch. New code has to build for at least one distro and
> >    ARM+x86 architectures (unless it is related to one arch or even one 
> >    machine).
> > 
> > 2. Marking recipes as buildable or not. With over 6000 of them it is
> >    really hard to check everything for status. We can remove many old
> >    versions but sometimes they are useful for some projects. I would   
> >    rather add things like BUILDABLE_armv4t = "1" into recipe or into
> >    conf/distro/include/${DISTRO}-status.inc file. Similar status for
> >    recipes which are known to not work for some archs.
> > 
> > 3. Dealing with non buildable stuff. We have 'nonworking' and 'obsolete' 
> >    dirs in metadata - both should be dropped in stable branch. Other
> >    recipes can be marked as not buildable or dropped from branch - I did
> >    not thought yet on it.
> > 
> > 4. Lifetime of branch. Will we do new stable release after 6 months or
> >    after one year? For how long stable branch will be supported by OE
> >    itself? I know that there will be companies which will provide
> >    support for longer time - thats what I do with Poky 'pinky' now.
> > 
> > What do you feel about it? Any opinions or suggestions? Want to join 
> > effort?
> 
> +1 from me.

+1 from me as well.

> I'd also suggest that it might be helpful if we could define one or a
> few "reference host configurations".  On this side of the pond, for
> commercial work that would be RHEL4 or RHEL5.  I'll volunteer to set up
> such a reference host, and document the necessary packages/patches
> required to build the stable branch on that platform.

I'd like to add Ubuntu 8.10.  Further, for each of these reference host
configurations we need to say what's installed, preferably by meta
packages (in Ubuntu's case, say ubuntu-minimal + ubuntu-standard) and
specific packages ('gcc', 'g++', etc..).  And I too can help with the
env.  FWIW, a chroot should be good enough for this..

-- 
Tom Rini

Re: RFC: new stable release

[Shane Dixon]

On Tue, 2009-03-17 at 09:35 -0700, Tom Rini wrote:

> 
> I'd like to add Ubuntu 8.10.  Further, for each of these reference host
> configurations we need to say what's installed, preferably by meta
> packages (in Ubuntu's case, say ubuntu-minimal + ubuntu-standard) and
> specific packages ('gcc', 'g++', etc..).  And I too can help with the
> env.  FWIW, a chroot should be good enough for this..
> 

8.04 might be a better target for a "reference machine" because it's an
LTS release (although I personally use 8.10).  I think that the goal
should be solid support for the longest (within reason of course) amount
of time.  If I intend to write a document for a vendor explaining how to
use OE as a build environment for their code, the intent should be that
I don't have to re-write it again and again over the course of the next
year (Ubuntu releases every 6 months).  

I think that one of the greatest reasons for a good solid branch is that
documentation can truly be reliable because we're not aiming at a moving
target.

-- 
Shane Dixon
Linux Engineer
Atmel Corporation
Office: 719.540.1123
E-mail: shane.dixon@atmel.com

Re: RFC: new stable release

[Tom Rini]

On Tue, Mar 17, 2009 at 05:06:19PM +0000, Shane Dixon wrote:
> On Tue, 2009-03-17 at 09:35 -0700, Tom Rini wrote:
> 
> > 
> > I'd like to add Ubuntu 8.10.  Further, for each of these reference host
> > configurations we need to say what's installed, preferably by meta
> > packages (in Ubuntu's case, say ubuntu-minimal + ubuntu-standard) and
> > specific packages ('gcc', 'g++', etc..).  And I too can help with the
> > env.  FWIW, a chroot should be good enough for this..
> > 
> 
> 8.04 might be a better target for a "reference machine" because it's an
> LTS release (although I personally use 8.10).  I think that the goal
> should be solid support for the longest (within reason of course) amount
> of time.  If I intend to write a document for a vendor explaining how to
> use OE as a build environment for their code, the intent should be that
> I don't have to re-write it again and again over the course of the next
> year (Ubuntu releases every 6 months).  

8.04 works for me, really.  The same set of packages actually works for
me on 7.10/8.04/8.10, and I hope 9.04 :)

-- 
Tom Rini

Re: RFC: new stable release

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 3655 bytes --]

Marcin Juszkiewicz wrote:
> Hi
> 
> I know that there were lot of talks about creating stable branch of 
> OpenEmbedded in last months. But we need stable branch for vendors which 
> use our product.
> 
> As some people know I am working for Bug Labs company. Their product 
> named 'BUG Linux' is based on Poky 'pinky' (last stable release). We 
> were considering switch to newer (but never released) version named 
> 'elroy' but recently we decided to switch to OpenEmbedded. 
> 
> But to what kind of OE? Development branch change every day and things 
> break from time to time, packages get version bumps without notifying 
> anyone etc. Other possibility would be switch to stable branch but 
> current one is deprecated and not maintained anymore.
> 
> So the situation looks like we will need new stable branch with few 
> maintainers (I will be one of them) and with proper policies for merging 
> updates from development tree of OE. I maintained OE branches used for 
> OpenZaurus/Familiar few years ago so can say that I have needed 
> experience for it.
> 
> Which things needs defining? I have few in mind:
> 
> 1. Adding new things. This should be possible only by backporting from
>    OE.dev tree and needs to be Acked by at least 2-3 developers which
>    use stable branch. New code has to build for at least one distro and
>    ARM+x86 architectures (unless it is related to one arch or even one 
>    machine).
> 
> 2. Marking recipes as buildable or not. With over 6000 of them it is
>    really hard to check everything for status. We can remove many old
>    versions but sometimes they are useful for some projects. I would   
>    rather add things like BUILDABLE_armv4t = "1" into recipe or into
>    conf/distro/include/${DISTRO}-status.inc file. Similar status for
>    recipes which are known to not work for some archs.
> 
> 3. Dealing with non buildable stuff. We have 'nonworking' and 'obsolete' 
>    dirs in metadata - both should be dropped in stable branch. Other
>    recipes can be marked as not buildable or dropped from branch - I did
>    not thought yet on it.
> 
> 4. Lifetime of branch. Will we do new stable release after 6 months or
>    after one year? For how long stable branch will be supported by OE
>    itself? I know that there will be companies which will provide
>    support for longer time - thats what I do with Poky 'pinky' now.
> 
> What do you feel about it? Any opinions or suggestions? Want to join 
> effort?

These are all good ideas.

I would also link to see the stable branch use a next branch, or 
frequent tagging, so people have a stable place to build from. This wasy 
we can accumulate several weeks of fixes, then run a "comprehensive test 
suite" against the meta-data. I have no illusions that every commit will 
be "perfect".

We should also have a list of "supported" machines. Where supported 
means that they build. I would love to add that the images are run 
tested, but we do not want add lots of manual testing to prevent us 
getting bogged down.

I want to see a stable branch that can evolve slowly, but not become 
bogged down with to much work per commit.

At the same time, this is allows drastic changes to occur in .dev, such 
us recipe deletion, autotools/toolchain changes, etc. But this does not 
mean .dev should becomes an un-buildable playground.

Should we start a wiki page where we can start collecting stable branch 
procedures and see what we can converge on as a definition of .stable? 
We can discuss point on the list and condense the discussion on the wiki.

Philip



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]