[OE-core] My thoughts on the future of OE?

[Koen Kooi]

Op 1 mei 2014, om 19:02 heeft Richard Purdie <richard.purdie at linuxfoundation.org> het volgende geschreven:

> I was asked what I thought were things that needed discussion at OEDAM.
> Sadly I won't be there but I thought it might help to write down my
> thoughts in a few areas.
> 
> Developer Workflow
> ------------------
> 
> Firstly, I think the big piece we need to address as a project is
> "developer workflow" as this is where people are struggling using it.
> 
> Unfortunately "developer workflow" means different things to different
> people? Which one do I mean then? I actually mean all of them. As some
> examples:

[snip use cases]

I notice none of the use case mention distro developers, but the paragraph above is vague enough to be interpreted as "we rock at distro stuff, we suck at app/product development". To clear up my confusion, could you say something about distro development? Something like "bitbake-prserv-tool import won't be glacially slow in the future" :)

After 5 OE-core based angstrom releases I can say that the 'Core OS' quality has improved a lot and I've made peace with the version update policy, but the overall experience for a downstream distro is painful. A lot of small, stupid and preventable mistakes combined are tedious to deal with. The most recent example I hit was xinput-calibrator losing XDG autolaunch support in the move to OE-core without mentioning it in the commit log. It took me a week (admittingly a spare time week, so maybe a single workday) to track it down and come up with a patch.

And there's a *big* stupid and preventable issue that is not really OE-cores fault, but more the yocto-projects fault: BSPs using linux-yocto.bbappend and doing:

	SRCREV = "githash"
	LINUX_VERSION = "3.12"

BSP maintainers assume only their BSP will be affected, but it affects *all* BSPs using linux-yocto.bbappends. This applied to all bbappends, but I've seen all meta-handheld machines jump up and down in PV due to other BSPs setting global vars. Ross deserves a big thank you for obsoleting mesa bbappends, that issues prevented angstrom from having a working GL version for >1 ARM silicon vendor.


> So my first ask is that we actually try and write down all these
> different cases which is no small task in itself. I've a start of a list
> above, we should probably put this into the wiki and have people add
> their own use cases (or use cases of those around them in their company
> etc.). The trouble is there are some many different variants!
> 
> Once we have some idea of the cases, we can start to put together some
> kind of plan about how we intend to help the given use cases and to try
> and prioritise them. Perhaps we should put some kind of weighting
> against them in the wiki and people can increase the numbers of say
> their top three desires.
> 
> Whilst this looks like an impossible problem, the good news is that I
> believe we can solve it and we actually already have a rather powerful
> toolbox to help work on it. I have a rough idea of a roadmap that can
> move us forward:
> 
> a) locked sstate - I know its not in master yet but I believe this is
> key to allowing some of the use cases where you want to change some
> number of things but keep the rest of the system the same.

This is something I would very much like to see happening. I've noticed at least 3 patches in the 'dora' stable branch that triggered pretty much a complete rebuild due to sstate+prserv. And when I apply a buildfix for recent host distros to e.g. gcc to meta-linaro-toolchain I trigger a complete rebuild as well. It would be a lot less churn in the package feeds if I could lock down everything in console-image. That way the 'core OS' packages won't have as much spurious updates as they have now.

regards,

Koen