[oe] Plans for OE classic future

[Frans Meulenbroeks]

2011/11/25 Tom Rini <tom.rini at gmail.com>

>
>
> <Putting on TSC hat>
> The problem with this mindset is that we don't want to have
> oe-core+meta-oe+etc and oe.dev diverge any more than they had at the
> start.  This is why at some point master needs to become read-only.
> Everyone and their master based project can still fetch and build and
> work.  But if you're going right now and saying "I need to start a new
> project and it should be oe.dev+master based", please speak up now
> about why you're unable to use oe-core+etc.  We can't solve what we
> don't know is a problem and frankly I think the TSC is of the mind
> that oe-core+etc is as good as or better than oe.dev.  If we're wrong,
> someone needs to tell us what's missing.
>

Well, there is at least the issue of machines and architectures.
Now it is probably not too big a deal to bring over a new machine and turn
it into a BSP layers, but adding another architecture is yet another thing.

We do have products that are based upon NIOS II. This architecture is
present in OE classic and not in OE core.
One of the issues is that the NIOS II toolchain is still based upon (iirc)
gcc 4.1.1
I do not see an upgrade of gcc/niosii happen in the near future (In the
past I did spent some time to see if I could move to a newer version, but
there were some issues, and afaik no one is working on this atm), and I
doubt oe-core is interested in having a 4.1.1 toolchain around.

Therefore probably our next niosii project will still be oe-classic based.
On the other hand we also have ppc projects and the next one might quite
well use oe-core (it is too late to switch for the current one as we need
to release next month).

(and more general: oe classic still has quite some recipes that are not in
oe-core or meta-oe (apart from the fact that the latter is not really too
open to contributions; see the email thread on id3lib from a while ago).

Frans