Re: RFC: new stable release

[Koen Kooi <k.kooi@student.utwente.nl>]

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