Re: RFC: new stable release

[Philip Balister <philip@balister.org>]

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