Re: RFC: new stable release

[Matteo Fortini <matteo.fortini@mta.it>]

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, 
>