On Wed, Feb 28, 2018 at 6:17 PM, Alexander Kanavin <alexander.kana...@linux.intel.com> wrote: > On 02/20/2018 12:45 PM, Burton, Ross wrote: >> >> Is now a good time to talk about splitting up meta-oe? Some layers are >> actively developed and maintained (one example: meta-python), others are >> basically bitrotting and only get touched when something else causes them >> to break world builds (one example: meta-gnome). I've long felt that >> meta-oe should be split up and the high quality layers managed in their >> own >> repositories so patches to them don't get held up by breakage in other >> sub-layers. >> >> Another advantage of splitting out the high quality layers is that we'd >> like to look at running more community layers through the Yocto >> autobuilder, and granular layers make that easier to manage. >> >> Comments? > > > I just read the whole discussion (been on holiday), and while it seems that > splitting layers is seen as too heavy-handed, there is still something that > I believe should be done: a policy for blacklisting and removing > unmaintained recipes. Such a policy should be: > > a) clearly defined; > b) consistently applied. > > If that is in place, I, as an oe-core maintainer, would be a lot more > willing to contribute to meta-oe, knowing that recipes I contribute to (for > example by fixing issues caused by changes in oe-core) are, in fact, used > and taken care of otherwise. However, me endlessly fixing well obsolete > gnome2 stuff is just a fast track to not caring anymore. Isn't there somebody outside willing/capable/having enough time to move to gnome 3? This would be the best way to end the gnome2 bit-rott discussion and we'd have a desktop which is commonly used and addresses touch input. I tried that many years ago but the blocker at that time was gobject-introspection. These times are over for long. I wanted to start this during christmas-holiday but then my music-machine turned into more efforts than expected... For those still wanting what's left over from gnome2 currently (for me gedit - I don't like gedit3 search..) there is at least the mate-project an alternative. > > So, which recipes are unmaintained? > > 1. Badly out of date compared to upstream development. Say, one year or more > between version provided by meta-oe master, and latest version released by > upstream. For example: What if something changes upstream that makes it very difficult or impossible for us to follow? Have no recent example for that but I think if gobject-introspection would have worked for us years ago, gnome2 would not be an issue anymore. You mention below that in this case a patch has to be sent out. A comment in the recipe would be good enough? > 2. Recipes which fail to build, and the situation hasn't been addressed, in, > say, six months. Yes: recipes not building are useless. Martin has done blacklisting in the late phase of his maintainer-ship. The only question I have here: Does not build mean for all archs or for just .. how many? > > Once either of these is established, the recipe enters a grace period before > it is removed. Any objection to such removal should come with a patch that > addresses the reason for it. > I remember the times of mass blacklisting (if I remember correct last was recipe-specific-sysroot) this was
* kind of alarm for me for those recipes I need / take care of * easy grep'able for those recipes I thought 'why not - I have some spare cycles left over' So my opinion: * Recipes not building for a time to be defined: 1. blacklist and after x month -> remove * Recipes outdated: same 1.blacklist (undo if somebody complains with patch commenting in the recipe why not to remove) 2. remove after a time period to be defined Problem/Challenge: The way this was handled in the past was an extra duty put on maintainer's shoulders. If somebody could create (or is there something already?) a script for that and append it to world builds... Andreas -- _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel