OpenEmbedded Technical Steering Committee 8 May 2012 Attending: Richard Purdie (RP) Paul Eggleton (bluelightning) Mark Hatle (fray) Koen Kooi (koen)
Apologies: Khem (khem) Minutes: Jefro (Jefro) ________________________________________________ Agenda & Summary 1. pick a chair fray 2. lingering issues a. raise awareness of "janitor" list, QA "bugs" => fray to ping Darren & Song => goal to have initial janitor communication with OE list end of May 3. new issues a. discuss communication with OE community about release-oriented phases => fray willing to manage page as TSC activity => future agenda: document release process => fray will stay in sync with Dave/RP/Song & create wiki when appropriate b. Yocto entering 1.3 planning phase tree is open, planning has begun, RP has announced to ml looking at 6-8 weeks from 1.2 to 1.2.1 c. pre/post install scripting (fray) proposal to encompass in set of actions instead of shellscripts can move actions offline to some extent long term goal, lower priority if you see pre/post install scriptlets, think about whether can be done more generically as an action, try to capture 4. status a. oe-core release update-alternatives - fray hopes to share something next week too large for 1.2.1 Paul added layer dependencies (LAYERVERSION & LAYERDEPENDS) batching offline possible => keep on agenda (jefro) RP needs help reviewing things discussed some policy changes to ease load release branch process sgarman putting together a candidate branch RP will merge it into oe-core denzil when ready some things pulled in ahead of master initialisation issues need to be ironed out timeframe: goal for 1.2.1 is 6-8 weeks after 1.2 b. elections thanks for service Tom welcome back Koen c. infrastructure update from Khem regarding build machine testing Angstrom mailing list admin - reports of pwds being lost, people being unsub'd from -members koen has reported problem to the board key: => action item (indented = older or remaining from prior meetings) -> note from prior meetings ________________________________________________ Raw Transcript (8:58:24 AM) Jefro: good morning all & welcome back koen (8:59:06 AM) koen: hey Jefro (9:02:23 AM) bluelightning [~paul@pdpc/supporter/professional/bluelightning] entered the room. (9:02:29 AM) bluelightning: hi folks (9:02:33 AM) fray: hello.. (9:02:36 AM) RP: yes, congratulations koen :) (9:02:39 AM) Jefro: morning fray (9:02:44 AM) fray: congrats, welcome back (9:02:52 AM) bluelightning: indeed, congrats koen (9:02:54 AM) Jefro: interactive agenda at http://piratepad.net/8M1h1fJl9Y (9:04:00 AM) bluelightning: having trouble accessing that here... (9:04:05 AM) Jefro: although I can't get to that now (9:04:39 AM) fray: ok, I'm back (9:04:42 AM) Jefro: dang, I just had it, too... new agenda in 1 min (9:05:07 AM) Jefro: if you guys want to pick a chair, i should have the agenda up in a sec (9:05:27 AM) ***fray can do it unless omeone else wants to (9:05:47 AM) RP: Khem isn't going to make it. I suggest we wish him a speedy recovery and that he be more careful in future ;-) (9:06:15 AM) RP: fray: fine with me (9:06:28 AM) ***koen is winding down a conference call (9:06:30 AM) fray: RP -- absolutely (9:06:41 AM) Jefro: ok - agenda here, but not interactive: http://pastebin.com/hpdr4ea8 (9:06:51 AM) ***fray waits for Jefro.. but while we wait.. anyone have any new topics? (9:07:59 AM) RP: I don't have anything specific (9:08:14 AM) bluelightning: nothing here (9:08:21 AM) RP: fray: you mean koen? (9:08:25 AM) fray: Ultimate Marvel Marathon ending w/ the Avengers was very cool.. otherwise I havn't done any real work since last Wednesday.. ;) (9:08:51 AM) ***fray was waiting for both, but Jefro posted the agenda before he hit return.. ;) (9:09:32 AM) koen: one extra item for infrastructure: mailinglist admin (9:09:38 AM) fray: Ohh I do have one topic, assuming we have some time... pre/post install scripting based on a question I got from outside of OE... (9:10:51 AM) fray: koen, ready? (9:11:09 AM) koen: yes (9:11:14 AM) fray: ok.. lets go.. (9:11:19 AM) fray: #1 - I volunteered (9:11:20 AM) Jefro: ok - new agenda with latest topics at http://pastebin.com/jKtNh4n2 (9:11:21 AM) koen: I clicked the wrong button and disconnected the call :) (9:11:50 AM) ***RP wishes he did that more often (9:11:53 AM) fray: #2a -- the release phases (9:12:15 AM) fray: I need to figure out who to sync with to start working on this.. (9:12:22 AM) RP: fray: 3a? (9:12:37 AM) fray: sorry, brain keyboard malfunction.. (9:12:44 AM) fray: I did mean 2a - janitor list (9:13:06 AM) fray: RP, do you know who is working on this for Yocto? I'll take the action to sync with them and then work on the publicity via OE (9:13:16 AM) RP: Darren was the person who raised the idea (9:13:28 AM) RP: fray: I'd think he'd be as good as anyone (9:13:34 AM) fray: I believe bugs in the bugzilla (yocto) are alredy being tagged janitor right? (9:13:41 AM) RP: fray: correct (9:14:13 AM) fray: ok.. I'll do that as my next step.. goal by end of May to have initial janitor communication w/ the OE list(s) (9:14:29 AM) fray: ok, onto 3a -- release process (9:14:33 AM) RP: fray: sounds good, thanks (9:14:44 AM) RP: fray: I know for this Song is working on sending something out (9:15:06 AM) RP: fray: Its been delayed as we're refining parts of the process for 1.3 but something should be out sooner than later (9:15:10 AM) fray: Ok. I'll sync with him and I think related to 3b... the tree is open and the planning has begun right? (9:15:30 AM) RP: Yes, and I did send out an email about this as agreed (9:15:49 AM) fray: cool.. ok.. again, sooner the better, but I'll hopefully start an OE wiki release phase page.. (9:15:50 AM) koen: about the release (9:16:03 AM) koen: can someone explain to me how the oe-core release branch for 1.2 works? (9:16:22 AM) koen: scott g only confused me and himself further and pointed to RP (9:16:32 AM) RP: koen: sgarman is putting together a candidate branch, I'll merge it to oe-core denzil when its ready (9:17:00 AM) RP: koen: As you'll have noticed, he's pulled things in there ahead of master and there have been a few other initialisation issues (9:17:09 AM) RP: koen: We need to get those ironed out (9:17:15 AM) koen: right (9:17:48 AM) RP: koen: clear now? (9:18:00 AM) koen: on the process, yes (9:18:09 AM) koen: timeframe we can debat on the oe-core list (9:18:27 AM) RP: koen: timeframe for merging patches or for release? (9:18:46 AM) koen: both :) (9:18:59 AM) koen: a rough idea (9:19:03 AM) RP: koen: patch wise I'll take a sensible looking tree (9:19:18 AM) RP: koen: release wise we are thinking 6-8 weeks after 1.2 for 1.2.1 (9:19:23 AM) RP: koen: depends on bugs being fixed though (9:19:56 AM) koen: for meta-oe the plan is to merge it weekly into the denzil branch (9:19:59 AM) fray: RP -- would the update alternatives stuff I'm looking at be a canidate for 1.2.1? I'm afraid it's likely too much (9:20:15 AM) fray: (especially if I do the complete rework we'd talked about) (9:20:22 AM) RP: fray: probably too big for that, we need a rework IMO (9:20:41 AM) ***fray is trying to judge the scoping of the patches.. and this seems reasonable.. (9:21:05 AM) fray: I'm just worried, bug-wise, about the less then steller runtime requirement/provide matching that happens today due to this issue.. (9:21:34 AM) RP: fray: I know you had a user hitting that but that is the only report we've had (9:22:02 AM) koen: the release does illustrate that the layer word is still like the wild west (9:22:09 AM) koen: some tracking master, some denzil (9:22:16 AM) koen: some doing nothing (9:22:38 AM) RP: koen: the first couple of iterations through the process do tend to be hardest... (9:22:44 AM) RP: koen: I'm hoping it will get easier (9:22:46 AM) koen: indeed (9:23:11 AM) fray: I remember talking about this a couple years ago, but did we ever come up with a compatibility value int he layer (beyond the readme) that would prevent use with say master -- or put up some type of a warning when not used with the branch/tag intended? (9:23:38 AM) bluelightning: I did add layer dependencies (9:23:44 AM) RP: Someone said to be earlier "people noticed that master was stabilising for a while this time". I pointed out that was the point! :) (9:23:45 AM) bluelightning: including version numbering (9:23:52 AM) ***koen also noticed that pretty much only oe-core, meta-oe and martins layers do PR bumps properly (9:23:54 AM) bluelightning: I'm not sure it's really being used though (9:24:10 AM) fray: bluelightning ahh, I didn't realize they made it.. are they in the Yocto documentation? (9:24:17 AM) RP: koen: This is one reason I do want to get automated PR handling (9:24:37 AM) bluelightning: fray: should be in the current documentation I believe (/me checks...) (9:25:03 AM) fray: I'd suggest we promote this then.. and if it's not adequate (or used) we figure out if there is some thing better we can suggst (9:25:27 AM) ***RP agrees (9:25:28 AM) koen: RP: right, but like the GNU_HASH thing, it's the canary in the coalmine (9:26:11 AM) RP: koen: We can just continue to advocate and communicate best practise (9:26:18 AM) fray: yup (9:26:38 AM) koen: </everything is broken mode> (9:26:39 AM) bluelightning: fray: see LAYERVERSION and LAYERDEPENDS in the variable list in the reference manual (9:26:44 AM) fray: IMHO advocacy, followed by requiring it (if people use it), or modify the underlying tech if it's not right (9:26:50 AM) fray: bluelightning thanks (9:27:16 AM) RP: fray: yes, promoting broken tech is wrong (9:27:36 AM) RP: if given a less broken solution anyway :) (9:27:53 AM) fray: yup.. we know there is a need and we need to advocate a solution... and fix it if necessary (9:28:01 AM) fray: ok.. anything further on this? (9:28:19 AM) koen: fray: release or layer police? (9:28:27 AM) fray: either (9:28:39 AM) ***fray is playing meeting chair.. ;) (9:28:48 AM) RP: koen: Its up to the maintainers.. (9:29:26 AM) koen: I had nothing further on either (9:29:32 AM) RP: We need to be mindful that some layers are maintained by volunteers in their spare time. We can therefore make zero "demands" (9:29:47 AM) fray: yup... (9:29:52 AM) RP: Just like I can make zero "demands" of people when they send patches against OE-Core (9:30:18 AM) fray: well, we can deman PR bumps and general code quality.. (but I understand, it's a balancing act) (9:30:37 AM) RP: Well, I can refuse a patch on given technical grounds (9:30:53 AM) fray: ok then.. shall we do 3c or skip to 4? (9:31:04 AM) RP: skip to 4 and come back (9:31:25 AM) fray: ok.. 4a... update-alternatives.. as mentioned earlier it's in progres.. I hope to have something to share next week.. (9:31:27 AM) fray: (maybe earlier) (9:31:46 AM) fray: the idea is to implement it in a similar way as the adduser/addgroupt to allow subpackage alternatives (9:32:13 AM) RP: fray: When you get something vaguely working, lets talk and do a kind of pre-review (9:32:24 AM) fray: ok.. sounds good (9:32:26 AM) RP: fray: I want to try and keep this simple if we can (9:32:38 AM) koen: on that subject, we need to restart the icon-cache and mime discussion (9:32:42 AM) fray: the format of the alternative links is what I think is the biggest change.. (9:32:48 AM) koen: it's taking an hour on first boot for me (9:32:55 AM) RP: fray: maybe call the class update-alternatives2.bbclass or something so we can break compatibility (9:32:56 AM) fray: koen, do those have similar pre/post install scriptlet generation issues? (9:33:08 AM) fray: RP, yup.. we can do that (9:33:17 AM) koen: fray: sort of (9:33:28 AM) fray: I was initially thinking using a different variable, so we could preserve the compatibility... (9:33:38 AM) koen: fray: the problem is that it only needs to get done once at first boot, not N times (9:33:45 AM) RP: koen: yes, I made runtime postinst type problems a P1 for 1.3 (9:33:51 AM) koen: RP: OK (9:33:58 AM) fray: is this a read-only root problem? i.e. keeps happening if the system can't be modified.. (9:34:09 AM) RP: fray: it will be (9:34:13 AM) fray: ya, assuming we can run QEMU, it's possible.. just we can't always run qemu.. (9:34:31 AM) fray: for the icon and mime case, has anyone looked into adding a native tool to construct it? (9:34:39 AM) RP: fray: there are multiple stages to solve it. Running once instead of 200 times would be a good start (9:34:45 AM) fray: :) (9:34:45 AM) RP: fray: running it offline would be better again (9:35:25 AM) fray: ok.. so batching it and offline are possibilities.. ok (9:35:34 AM) RP: The trouble is the previous patches didn't take into account all the variables. There was also some gaps in the author's knowledge which scared me off the patches in the end :( (9:35:45 AM) fray: jefro, we should definitely mention these in the notes for future agenda work, under status... (9:35:58 AM) ***Jefro ok (9:35:59 AM) RP: I would note that I need more help with review of things (9:36:14 AM) RP: I'm drowning trying to maintain the quality bar (9:36:36 AM) fray: RP, ya.. I expect that to be the case with these things.. (slipping into 3c for a second) it was mentioned debian has a core set of about 55 actions.. we might want to look at them and see if the actions themselves [not implementation] are something we could use to help organize this work (9:37:05 AM) RP: fray: There are about three main pain points at the moment (9:37:09 AM) fray: RP -- would more acked-by or reviewed-by responses help? (9:37:50 AM) RP: fray: Yes, but I'd also like people to think about the changes they're proposing. There are a lot of "this works for me and I don't really care about XXX" (9:38:07 AM) RP: As above, we can't demand they fix it but on the other hand, it can't be me who fixes these things (9:38:15 AM) RP: or even explains how to fix them (9:38:25 AM) fray: ya, I certainly understand that... (9:39:00 AM) fray: sounds like it's time to start coming up with area maintainers to help feed and respond to people (9:39:14 AM) RP: I'm open to ideas on how we look at this but yes, sub maintainers were how I thought this might work (9:40:03 AM) RP: I put this very badly in an email recently and Martin got upset :( (9:40:44 AM) fray: I hate to suggest more mailing lists.. but would an oe-core-discussion list help? I'm getting swamped betwen the patches and the discussions just trying to follow things (9:40:56 AM) fray: I'm apparently missing discussions because of this (9:41:15 AM) bluelightning: fray: sometimes patches turn into discussions though (9:41:18 AM) RP: fray: Its probably my fault as it happened against a set of patches (9:41:39 AM) fray: bluelightning ya, discussion to me is where something relates to architecture, overall oe-core, policy, etc.. (9:41:49 AM) fray: I'm really not convinced another list is the right answer.. but it might help (9:42:07 AM) ***RP doubts another list would help (9:42:27 AM) RP: fray: In particular I was frustrated at the glib upgrade keep coming back despite it being known to break at runtime. (9:42:52 AM) ***fray wishes he knew more about glib to help.. Hmm.. (9:43:13 AM) RP: fray: that one is in now, got it sorted at the weekend but its just an example of an ongoing issue (9:43:19 AM) fray: I can certainly accept more lists is not the answer.. I'm not sure I have a suggestion at this point (9:43:58 AM) RP: Another part of this is that I'm not daring accept patches since I know I'll end up having to spend time fixing them if the builds break as a result. I should probably just freely revert things :/ (9:44:35 AM) RP: Anyhow, I guess my ask is that the TSC thinks about these things (9:45:02 AM) fray: I'm certainly in the revert it if it doesn't work camp.. (9:45:08 AM) ***bluelightning too (9:45:13 AM) fray: I've caused my shared of un-intended problems.. but I won't take objects to a revert (9:45:24 AM) fray: s/objects/offense/ (9:45:38 AM) RP: reverts tend to upset people a lot... (9:45:46 AM) RP: "Why couldn't you just fix it" (9:45:48 AM) bluelightning: they do pollute the history as well (9:45:59 AM) RP: that is the thing I really dislike (9:46:09 AM) RP: particularly if a change is going to end up going in (9:46:26 AM) bluelightning: it depends on how far off the fix is really (9:46:31 AM) fray: RP, I understand the why didn't you just fix it.. if it's a one-line fix.. but if it takes debugging of any kind, I don't mind the revert.. (of course preventing it from going in first is even better.... but not always reality) (9:46:32 AM) bluelightning: and how serious the breakage (9:46:56 AM) RP: I've been trying to work on the prevention front, its just hard work (9:47:30 AM) RP: Anyhow, just take this as a sign that I'm wondering if we need to readjust the balances/thresholds (9:48:31 AM) fray: I assume it is.. something has to happen... between sub maintainers and reverts being policy, and more tools for you... (9:48:45 AM) fray: (sorry I have to do something, be back in 1-2 minutes) (9:49:44 AM) RP: so in Khem's update, he mentioned there is now an OE machine doing test, of angstrom at the moment since YP has OE-Core covered (9:50:25 AM) RP: This sounds good, I'd be interested to know how failures are being tracked down anf regressions fixed. Autobuilds are a lot of work as I know all too well... (9:50:35 AM) RP: koen: mailing list admin? (9:50:36 AM) fray: back -- ugh office just got hit by hail.. (9:50:52 AM) RP: fray: np, just tried to move forward a bit in your absence (9:50:55 AM) fray: np (9:51:03 AM) koen: RP: passwords are lost and people were unsubscribed from -members (9:51:13 AM) koen: so our elections might have not been valid (9:51:29 AM) RP: koen: lost by who? (9:51:38 AM) RP: koen: and do we know who was unsubscribed? (9:51:46 AM) koen: at least ken gilmer was (9:51:47 AM) RP: koen: Isn't that a matter for the board? (9:51:59 AM) koen: we're in charge of infra (9:52:13 AM) koen: but I'm fine with moving these problems to the board (9:52:18 AM) RP: koen: subscribed by someone or by bounce issues? (9:52:32 AM) RP: er, unsubscribed (9:53:35 AM) fray: Hmm, sounds like this is definitely something the board needs to deal with.. since it involved governance and member communications (9:54:16 AM) RP: koen: Can you send a summary of the problem to the board and I'd cc Phil Blundell too since he does have admin access. I'm happy to be on cc to help facilitate if required (9:55:44 AM) RP: We have 5 mins left btw (9:56:02 AM) koen: I already informed crofton (9:56:07 AM) fray: ok.. if we're done w/ that.. any other issues.. or I'll quickly describe 3c.. (9:56:14 AM) RP: fray: go for it (9:56:27 AM) RP: koen: did you get a response? Did he direct this to the TSC? (9:56:33 AM) fray: Ok, so I was talking to someone about pre/post install scripts.. and how OE generated many of them using hte classes.. (9:56:46 AM) fray: we got into a discussion about how currently they are all shell based, but they don't really need to be. (9:57:24 AM) fray: It would be interesting if all of the pre/post actions could be encompsed into a standard set of actions (thus the debian has about 55 actions), and then dynamically generated to fit the best language for a package manager, or even a simple usage situation.. (9:58:13 AM) fray: This is something that I consider a long-term goal, but does anyone else thing this is worth pursuing, primarily starting with what are all of the pre/post install scripts doing.. and can we better standardize them.. and then eventually can we implement these using generic and/or package manager specific implementations? (9:58:43 AM) RP: fray: I think the biggest win at the moment would be to make as much as we can happen offline (9:59:13 AM) RP: fray: There are other developments such as those you mention which I can see value in but they're not of the highest priority right now (9:59:19 AM) fray: Ya, that discussion also prompted this.. if we could collection the actions, and some how batch them -- or even generate a system wide configuration from them.. we may have a good performance improvement as well (9:59:31 AM) fray: RP, I agree.. this is longer term thinking.. (9:59:40 AM) RP: fray: I know opkg has the idea of intercepts fwiw (10:00:19 AM) fray: ok, we've got one minute.. I'll leave the discussion with the comment.. if you see pre/post install scriptlets.. figure out if this is something that can be generically done and benefit other packages as well.. if it can.. we may want to somehow capture these.. (10:00:24 AM) RP: fray: it only does this for ldconfig atm (puts in a script called ldconfig first in PATH, notices if it gets executed, then runs at the end of the pkg operation) (10:00:45 AM) fray: RP, ya some versions of RPM have a similar cached ldconfig.. (10:01:52 AM) ***RP will give it thought (10:02:20 AM) fray: ok.. with that.. I think we're done unless anyone has anything else (10:02:48 AM) fray: ok, have a good day everyone.. (10:03:31 AM) ***fray goes to check his car for hail damage.. :( (10:03:36 AM) RP: not from me, thanks all! (10:03:50 AM) Jefro: adios all -- Jeff Osier-Mixon http://jefro.net/blog Yocto Project Community Manager @Intel http://yoctoproject.org _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
