[oe] 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