<span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><div> oe-tsc minutes, 16-Jun-2011</div><div><br></div><div>Attending: Koen, Khem, Tom, Richard, Mark</div>
<div>Apologies: Stefan</div><div>Notes: Jefro</div><div><br></div><div>Agenda</div><div><br></div><div>01) choose a meeting chair</div><div><br></div><div>Tom</div><div><br></div><div>02) topics</div><div><br></div><div><div>
khem: fallback source mirror for oe-core</div><div> premirrors? who maintains no-longer-upstream mirror?</div><div> kitchen-sink mirror is not a benefit for oe-core, but it is beneficial for yocto, angstrom</div><div> "mirror" becomes a distro concept</div>
<div> meta-oe is not a distro, won't have a policy</div><div> oe-core on its own will degrade over time - ok, as oe-core -only users are advanced?</div><div> khem thinks adding fallback mirrors not a bad choice, given certain constraints</div>
<div> -->when we have a release we can revisit if it's appropriate there</div><div><br></div><div>khem: patches appearing for recipes on oe-dev:</div><div> --> khem to send email regarding "put stuff in meta-oe"</div>
<div><br></div><div>"long" term support for 2011.03-maintenance</div></div><div> --> Tom to change strategy for maint branch, oe.dev master to oe-core/meta-oe/layer</div><div><br></div><div>khem: promote devs to participate in oe-user</div>
<div> --> on agenda for next week</div><div><br></div><div>03) action items from last week</div><div><br></div><div>mark: posted the Commit & Policy Guidelines on the wiki, to much fanfare</div><div>tom: GNOME stuff moving along</div>
<div>RP: sent email to board, no response yet</div><div><br></div><div>04) TSC structure & elections</div><div><br></div><div>--> RP to send a note to board asking for status on prior message</div><div><br></div><div>
05) Status updates</div><div> - oe-core</div><div> discussions about multilib, tuning files</div><div> - bsp guidelines</div><div> - metadata layer splitting</div><div> - infrastructure</div><div><br>
</div><div>Raw Transcript</div><div><br></div><div>(1:01:00 PM) Tartarus: I'll chair, too, if no one has already volunteered</div><div>(1:01:15 PM) Jefro: hi Tartarus - no one has volunteered yet, congratulations</div>
<div>(1:02:46 PM) Jefro: Agenda is at <a href="http://pastebin.com/PhJpWfjr" target="_blank" style="color: rgb(0, 0, 204); ">http://pastebin.com/PhJpWfjr</a></div><div>(1:02:52 PM) Tartarus: thanks</div><div>(1:03:01 PM) Tartarus: waiting on Khem, but, #2, new items?</div>
<div>(1:03:07 PM) fray: I don't hve anything to add</div><div>(1:03:14 PM) ***Tartarus has none</div><div>(1:03:25 PM) Tartarus: RP? koen? khem?</div><div>(1:03:35 PM) Tartarus: (and khem's no or new topics will move us on to #3)</div>
<div>(1:04:01 PM) Jefro: stefan sends apologies</div><div>(1:04:18 PM) khem: ich bin hier</div><div>(1:04:28 PM) fray: (we on 3 then?)</div><div>(1:04:40 PM) Tartarus: Well, i thought RP and koen would reply quickly ;)</div>
<div>(1:05:04 PM) Tartarus: RP__ ? (for making his irc client beep, presumably)</div><div>(1:06:12 PM) khem: I think fall back src mirror for oe-core</div><div>(1:06:20 PM) khem: we could talk about that</div><div>(1:06:43 PM) Tartarus: fine by me</div>
<div>(1:07:03 PM) fray: good topic.. I have some minor input for that</div><div>(1:07:12 PM) Tartarus: RP__, koen, ping?</div><div>(1:08:07 PM) koen: pong</div><div>(1:08:12 PM) Tartarus: new topics?</div><div>(1:09:04 PM) khem: I am seeing some new patches for recipes on oe.dev</div>
<div>(1:09:26 PM) khem: I guess because people adopted releases and are now posting the updates</div><div>(1:09:38 PM) Tartarus: khem: So, you want to bring up discussion winding down oe.dev?</div><div>(1:09:41 PM) khem: so how should we handle that</div>
<div>(1:10:14 PM) Tartarus: Or just that topic, new work going into oe.dev and what to tell/remind people?</div><div>(1:10:16 PM) khem: Tartarus: yeah should we change the policy for release branch</div><div>(1:10:23 PM) khem: where it can take patches if needed</div>
<div>(1:10:32 PM) khem: but the new patches what to do about those</div><div>(1:10:38 PM) Tartarus: khem, hm?</div><div>(1:10:39 PM) khem: some recipes are not in any layer</div><div>(1:10:50 PM) Tartarus: well, hang on</div>
<div>(1:10:56 PM) Tartarus: ok, new topic added to the list</div><div>(1:10:58 PM) koen: Tartarus: "long" term support for 2011.03-maintenance</div><div>(1:11:17 PM) khem: and I would like to promote devs to participate in oe-user</div>
<div>(1:11:18 PM) Tartarus: ok, so we've got oe-core mirror, dev happening in oe.dev and 2011.03-maint long term</div><div>(1:11:19 PM) RP__: soory brb</div><div>(1:11:40 PM) Tartarus: and promoting oe-user</div><div>
(1:11:44 PM) Tartarus: got all that so far, Jefro?</div><div>(1:11:50 PM) koen: oe-user?</div><div>(1:11:54 PM) khem: ml</div><div>(1:12:10 PM) koen: didn't we say that should go away we'd only have 1 list?</div><div>
(1:12:11 PM) ***fray is sorry to say he didn't know there was an oe-user</div><div>(1:12:12 PM) khem: to encourage more devs</div><div>(1:12:34 PM) Tartarus: koen: it's added to the topic list, we'll cover history then</div>
<div>(1:12:40 PM) khem: fray: if you go to <a href="http://lists.linuxtogo.org/" target="_blank" style="color: rgb(0, 0, 204); ">lists.linuxtogo.org</a></div><div>(1:12:47 PM) khem: and grep for OpenEmbedded</div><div>(1:12:51 PM) Tartarus: Lets move on to #3 and let RP give any new topics when he's back again</div>
<div>(1:12:51 PM) khem: you will see all of them</div><div>(1:13:02 PM) fray: sounds good..</div><div>(1:13:11 PM) Tartarus: #3, AI updates</div><div>(1:13:14 PM) Tartarus: I know fray has one</div><div>(1:13:21 PM) Jefro: Tartarus - yes, I have it all</div>
<div>(1:13:34 PM) fray: my status update.. the Commit & Policy Guidelines were posted on the Wiki. An email has been sent to the oe-dev & oe-core lists with that information on behalf of the TSC</div><div>(1:13:54 PM) fray: One minor note. I found a small typo in one spot and fixed it before posting the final version. I assume that's not a problem. ;)</div>
<div>(1:14:04 PM) khem: I dont think so</div><div>(1:15:00 PM) Tartarus: Anyone else have AIs?</div><div>(1:15:20 PM) Tartarus: GNOME stuff seems to be moving along, but maybe that was already last week</div><div>(1:15:22 PM) fray: RP had one for the election info.. I haven't seen a response yet</div>
<div>(1:15:40 PM) Tartarus: Ah yes, need to see if the board replied just to RP or something, when he's back</div><div>(1:15:41 PM) Tartarus: thanks</div><div>(1:15:52 PM) Tartarus: And elections is #4 too</div><div>(1:15:54 PM) koen: I think the election stuff is in the boards court now</div>
<div>(1:16:02 PM) RP__: Sorry guys, I had a phone call I needed to take</div><div>(1:16:07 PM) RP__: back now</div><div>(1:16:07 PM) Tartarus: koen: right</div><div>(1:16:09 PM) fray: I'm not sure what else we can do beyond the letter to the board</div>
<div>(1:16:15 PM) khem: RP__: NMI ?</div><div>(1:16:26 PM) Tartarus: RP__: working backwards, elections stuff? We know the email was sent telling the board what's what</div><div>(1:17:00 PM) RP__: khem: right :/</div>
<div>(1:17:18 PM) Tartarus: I'd like to propose RP send the board a ping email, since it's been a week</div><div>(1:17:23 PM) RP__: Tartarus: Afaik the board accepted it and the ball is in their court</div><div>(1:17:29 PM) ***RP__ agrees</div>
<div>(1:18:08 PM) Tartarus: RP__: so, any new agenda items you want to add?</div><div>(1:18:50 PM) ***RP__ is ok with the agenda </div><div>(1:18:55 PM) Tartarus: k</div><div>(1:19:07 PM) Tartarus: So, anything more we can do for #4? Or other AIs from the last meeting there's status on?</div>
<div>(1:19:13 PM) Tartarus: I think no for #4 and #3</div><div>(1:20:42 PM) Tartarus: going once...</div><div>(1:20:54 PM) Tartarus: twice</div><div>(1:21:14 PM) Tartarus: sold! On to #5, status updates time</div><div>(1:21:41 PM) Tartarus: oe-core, RP?</div>
<div>(1:22:06 PM) RP__: I'm keeping a lower profile than usual as I'm trying to sort out various multilib work</div><div>(1:22:23 PM) RP__: The designs weren't working and we had a team member leave so I'm trying to resolve that</div>
<div>(1:22:31 PM) Tartarus: OK. Any idea when you'll poke your head out again on multilib and ask for more?</div><div>(1:22:45 PM) RP__: Tartarus: ask for more what?</div><div>(1:22:47 PM) Tartarus: (help, comments, testers)</div>
<div>(1:22:54 PM) khem: he already did</div><div>(1:23:07 PM) khem: few days ago</div><div>(1:23:10 PM) Tartarus: Yes, sorry, I mean after a few days ago</div><div>(1:23:12 PM) fray: Monday was it?</div><div>(1:23:21 PM) ***khem has not yet read that long email yet</div>
<div>(1:23:21 PM) RP__: Tartarus: I've put some questions out for discussion</div><div>(1:23:28 PM) ***Tartarus does owe reading it over and thinking again, silly pays the bills stuff...</div><div>(1:23:40 PM) RP__: I'm trying to implement things and discovering issues with the proposal already though</div>
<div>(1:23:54 PM) Tartarus: k</div><div>(1:23:55 PM) koen: fray: you need to remember that rpm is "from the future" and deb/ipk is "KISS"</div><div>(1:24:12 PM) Tartarus: I guess, unless you say otherwise RP__, lets go with to the ML with multilib stuff</div>
<div>(1:24:21 PM) RP__: ML is fine</div><div>(1:24:28 PM) Tartarus: OK, any other status updates?</div><div>(1:24:34 PM) RP__: I just wanted to highlight I'm distracted atm and Saul is also away for a week</div><div>(1:24:35 PM) Tartarus: infra? layers? bsp stuff?</div>
<div>(1:24:40 PM) RP__: please just bear with me :)</div><div>(1:24:48 PM) fray: koen, haha</div><div>(1:24:55 PM) khem: I am working on svn based 4.6 recipes for gcc</div><div>(1:25:07 PM) fray: I'm ripping my hair out currently with the directory ownership and user/group/mode collisions..</div>
<div>(1:25:17 PM) fray: (luckily I have an excess of hair to pull out)</div><div>(1:25:21 PM) Tartarus: ha</div><div>(1:25:44 PM) koen: I have had people asking about sample layers/bsps</div><div>(1:25:55 PM) khem: We have converged the meta-oe gcc recipes to use bbappend if people have not noticed</div>
<div>(1:26:05 PM) Tartarus: i'm starting to figure on local autobuilder and merging stuff from oe.dev to meta-oe/etc</div><div>(1:26:10 PM) koen: a lot of people look at meta-intel and go "meh", so we need a decent example</div>
<div>(1:26:40 PM) khem: I need meta-intel to build angstrom for my netbook havent succeeded yet</div><div>(1:26:47 PM) RP__: koen: why go meh?</div><div>(1:26:55 PM) RP__: koen: We can fix something if necessary</div><div>
(1:27:14 PM) khem: RP__: fix n450.conf</div><div>(1:27:23 PM) RP__: khem: cool on gcc</div><div>(1:27:28 PM) RP__: khem: fix how?</div><div>(1:27:41 PM) khem: does not work with angstrom</div><div>(1:28:16 PM) khem: $ MACHINE=n450 bitbake console-image</div>
<div>(1:28:16 PM) khem: ERROR: Unable to parse conf/bitbake.conf: Could not include required file conf/machine/atom-pc.conf</div><div>(1:28:18 PM) Tartarus: khem, I think the answer is "we" need to pull stuff out of poky if needed and into oe-core/etc</div>
<div>(1:28:23 PM) Tartarus: or meta-intel or ...</div><div>(1:28:24 PM) koen: RP__: meta-intel is not how someone would handle a bsp migrating for either old-oe or something different</div><div>(1:28:36 PM) RP__: khem: ick. I'll ensure that gets fixed asap</div>
<div>(1:28:38 PM) koen: RP__: the biggest "problem" is linux-yocto</div><div>(1:28:49 PM) koen: RP__: and x86 is no good fit for arm in general :)</div><div>(1:29:07 PM) RP__: koen: ok, those are two things which are harder to change</div>
<div>(1:29:10 PM) koen: RP__: the missing atom-pc is what that mailinglist thread was about</div><div>(1:29:24 PM) RP__: koen: I know that, I didn't realise it was breaking something in meta-intel though</div><div>(1:29:52 PM) koen: RP__: Tom Z is adding the meta-yocto dep to README, so the problem is a bit less severe now</div>
<div>(1:29:56 PM) fray: note IMHO missing atom-pc is just the tip of a problem.. (yes it needs to be fixed, but... the definitional of the machines, tunings, architectures, etc are very confusing today)</div><div>(1:30:18 PM) RP__: fray: please can we let that one rest for just a little longer? ;-)</div>
<div>(1:30:33 PM) fray: thats fine, there are other more pressing issues</div><div>(1:30:35 PM) Tartarus: nmi from the baby, bbi2</div><div>(1:30:39 PM) khem: fray: all common arch tune files belong to oe-core I would say</div>
<div>(1:30:54 PM) RP__: khem: That isn't what fray is referring to</div><div>(1:31:01 PM) fray: khem, thats fine.. but that is something else</div><div>(1:31:16 PM) RP__: khem: currently we merge architecture, ABI and tuning information together</div>
<div>(1:31:25 PM) khem: yes</div><div>(1:31:26 PM) fray: read my email on the mailing list if you have questions..</div><div>(1:31:31 PM) koen: I think fra wants to take a step back and make all the tune files look the same</div>
<div>(1:31:45 PM) RP__: koen: split the tune files up more</div><div>(1:31:45 PM) koen: and seperate tuning from ABI</div><div>(1:31:57 PM) fray: koen, partially.. some of it is splitting them up more.. and some of it is simply making them consistent</div>
<div>(1:32:13 PM) khem: yeah we need machine.conf arch.conf abi.conf</div><div>(1:32:23 PM) RP__: I'm not against any of this but I would like to have some kind of multilib test framework alongside it</div><div>(1:32:38 PM) Tartarus: ok, she's down for a nap, back</div>
<div>(1:32:47 PM) khem: Tartarus: thats was quick</div><div>(1:33:00 PM) RP__: and given the currently development situation, I think having some kind of multilib code first might be helpful</div><div>(1:33:11 PM) khem: Tartarus: dont make too much noise typing now :)</div>
<div>(1:33:15 PM) Tartarus: khem: I didn't say she's asleep ;) She is however, in her crib and will fall asleep soon</div><div>(1:33:29 PM) RP__: (I don't want to redesign tune, then find it doesn't work for multilib and have to redesign again)</div>
<div>(1:33:43 PM) Tartarus: RP__: makes sense</div><div>(1:33:57 PM) fray: RP__, my fear is what is there today won't work with multilibs -- or will introduce significant extra work</div><div>(1:34:01 PM) khem: yes multilib is part of this puzzle definitely</div>
<div>(1:34:09 PM) RP__: fray: I don't worry about this ;-)</div><div>(1:34:29 PM) RP__: fray: Worst case I write some very specific multilib configs, then we generalise them later</div><div>(1:34:42 PM) RP__: We have much bigger issues around atm :(</div>
<div>(1:35:01 PM) RP__: e.g. there is no sane way we can have : in PN</div><div>(1:35:07 PM) fray: ya.. the permissions file & directory really worries me as someone focused on userspace..</div><div>(1:35:20 PM) fray: I can't actually show today that from one build to the next we'll get the same FS</div>
<div>(1:35:46 PM) RP__: fray: :/</div><div>(1:35:59 PM) koen: fray: the sstate repackaging changes shlibs deps from time to time as well</div><div>(1:36:01 PM) RP__: fray: You're making progress and have a solution in mind though?</div>
<div>(1:36:17 PM) RP__: koen: ?</div><div>(1:36:20 PM) koen: e.g. <a href="http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/testlab/commit/?h=yocto&id=ac74418adb163a2b5120a9220ac8668860a09fc3" target="_blank" style="color: rgb(0, 0, 204); ">http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/testlab/commit/?h=yocto&id=ac74418adb163a2b5120a9220ac8668860a09fc3</a></div>
<div>(1:36:22 PM) fray: yes, I am making progress.. solution will be a mix of distro configuration, detecting the issue, and fixing recipes</div><div>(1:36:58 PM) khem: fray: only sane way to do that is if we can schedule the build in same sequence everytime</div>
<div>(1:37:07 PM) khem: otherwise nullify autoconf</div><div>(1:37:21 PM) khem: by providing cached output</div><div>(1:37:24 PM) fray: khem, the build ORDER is similar (the same within reason) due to the build-time deps..</div>
<div>(1:37:38 PM) RP__: khem: I don't understand that...</div><div>(1:37:38 PM) khem: fray: even that may not be enough</div><div>(1:37:40 PM) fray: the problem is at install time, whatever creates a directory "first" sets the permissions for the directory.. (same for files)</div>
<div>(1:37:42 PM) khem: depends whats staged</div><div>(1:37:57 PM) fray: this is a bug in nearly all of the recipes today..</div><div>(1:37:59 PM) khem: ups we are talking about different things nm</div><div>(1:38:17 PM) RP__: fray: A hack for now might be to add a do_install postfunc which fixes up the owners/permissions</div>
<div>(1:38:22 PM) fray: good example is a lot of things in my build are creating "/usr/lib" as 0775.. when it should be 0755.. :P</div><div>(1:38:35 PM) fray: RP__ I'm working on cleaning things in the package.bbclass</div>
<div>(1:39:06 PM) khem: fray: so we can keep updating one's to umask may be</div><div>(1:39:16 PM) RP__: koen: thats rather worrying :/</div><div>(1:39:24 PM) fray: heh.. unfortunately thats not enough.. but will likely help some..</div>
<div>(1:41:02 PM) Tartarus: OK, any more commentary here before we pick up the new topics?</div><div>(1:41:09 PM) fray: nothing for me</div><div>(1:41:29 PM) koen: RP__: it's hard to reproduce, so I suspect some race issue with sstate and the shlib code</div>
<div>(1:42:33 PM) RP__: koen: If you can produce a testcase...</div><div>(1:42:42 PM) RP__: Tartarus: nothing from me</div><div>(1:42:46 PM) koen: RP__: I've been trying to</div><div>(1:42:50 PM) koen: Tartarus: no, let's move on</div>
<div>(1:42:53 PM) Tartarus: OK, so moving on</div><div>(1:42:56 PM) Tartarus: oe-core and mirrors</div><div>(1:43:00 PM) Tartarus: Been a little talk</div><div>(1:43:20 PM) Tartarus: I didn't see anything after my suggestion of a last resort for oe-core and making sure it's easily configurable for distros to provide whatever they feel is best</div>
<div>(1:43:34 PM) Tartarus: (eg poky and angstrom making sure stuff is never missed, if they want)</div><div>(1:43:36 PM) fray: with the mirror.. One additional comment beyond what I sent to the list -- should we have PREMIRRORS? I'm thinking no.. since we want to go to the upstream.. if that fails, THEN fall back to the MIRROR</div>
<div>(1:44:00 PM) Tartarus: In general or?</div><div>(1:44:02 PM) fray: I don't have any issues with yocto, angstrom, or anything else being the default fall-back..</div><div>(1:44:05 PM) fray: for oe-core</div><div>(1:44:10 PM) RP__: Tartarus: You're not clear, you're saying just to default to what?</div>
<div>(1:44:23 PM) ***RP__ probably isn't 100% up to date on the email thread :/</div><div>(1:44:37 PM) Tartarus: RP__: I'm saying oe-core should have no PREMIRRORS and a MIRRORS that's only got no longer upstream stuff</div>
<div>(1:44:44 PM) Tartarus: so it's a last resort</div><div>(1:44:51 PM) fray: Tartarus that should be a bare minimum...</div><div>(1:44:58 PM) RP__: Tartarus: Who maintains the no longer upstream stuff mirror?</div><div>
(1:44:59 PM) Tartarus: But let poky and angstrom and anyone else fill in with whatever mirror they want</div><div>(1:45:07 PM) fray: but wouldn't cover the case where something "goes away".. i.e. who adds it to the mirrors</div>
<div>(1:45:09 PM) RP__: We do that today...</div><div>(1:45:11 PM) Tartarus: RP__: Whomever does that today, assuming they want to continue</div><div>(1:45:12 PM) khem: fray: yeah no premirrors</div><div>(1:45:30 PM) Tartarus: fray: The mirror shouldn't be added to easily/often, it's a last resort</div>
<div>(1:45:33 PM) RP__: The question is whether OE-Core should benefit from work done by yocto/angstrom</div><div>(1:45:36 PM) Tartarus: eg tinylogin is just not anywhere anymore? OK, add it</div><div>(1:45:43 PM) Tartarus: tzdata changed again? Time for a new recipe</div>
<div>(1:45:56 PM) khem: RP__: <a href="http://sources.oe.org/" target="_blank" style="color: rgb(0, 0, 204); ">sources.oe.org</a> is maintained by me and Tom K</div><div>(1:46:09 PM) fray: my concern is that if we rely (in oe-core) on the mirrors too heavily, then missing upstreams will be "missed"...</div>
<div>(1:46:12 PM) Tartarus: RP__: I think the answer is that a has everything mirror ISN'T a benefit for oe-core</div><div>(1:46:17 PM) Tartarus: It IS for angstrom, poky, etc</div><div>(1:46:22 PM) Tartarus: But oe-core we want to know when stuff moves</div>
<div>(1:46:47 PM) khem: yes thats my understanding too</div><div>(1:46:48 PM) Tartarus: Since that means a recipe needs work or something really did go away</div><div>(1:46:50 PM) RP__: Tartarus: I think we're just adversely affecting users if we do that</div>
<div>(1:46:52 PM) fray: I'm not against "meta-oe" having premirrors, or point to full mirrors.. since I consider that the "distribution"</div><div>(1:47:02 PM) Tartarus: RP__: what users? oe-core only users?</div>
<div>(1:47:09 PM) RP__: Tartarus: yes</div><div>(1:47:18 PM) Tartarus: We expect a certain amount of depth on people not relying on any distro</div><div>(1:47:35 PM) Tartarus: I'd expect every distro to have or point at a real mirror</div>
<div>(1:47:44 PM) khem: anybody who uses oe-core needs to have a distro hisown or some predefined</div><div>(1:47:51 PM) fray: thats my thought.. oe-core is "not a distro".. meta-oe, poky, angstrom, et al are</div>
<div>(1:47:55 PM) khem: so mirror becomes distro thing then</div><div>(1:48:07 PM) koen: meta-oe is not a distro</div><div>(1:48:13 PM) koen: it won't have any policy</div><div>(1:48:18 PM) ***khem nods</div><div>(1:48:21 PM) RP__: This means that releases of OE-Core will degrade badly with time</div>
<div>(1:48:26 PM) Tartarus: RP__: why?</div><div>(1:48:47 PM) RP__: Tartarus: As things get deleted upstream, it relies on someone adding them to the minimal mirror</div><div>(1:48:53 PM) fray: I would expect an update to oe-core, or a (supported) tag if something goes missing upstream</div>
<div>(1:48:58 PM) Tartarus: No, it relies on people using the distro for that release</div><div>(1:49:00 PM) fray: -- or to the minimal mirror</div><div>(1:49:05 PM) Tartarus: again, jsut a release of oe-core won't be of much use</div>
<div>(1:49:19 PM) RP__: Tartarus: so the OE-Core release standalone degrades badly over time</div><div>(1:49:19 PM) Tartarus: without a release of angstrom and meta-oe and so on or poky based on it or ...</div><div>(1:49:45 PM) Tartarus: RP__: Yes, and I don't think that's a problem. Anyone using oe-core by itself is expected to have depth</div>
<div>(1:49:53 PM) Tartarus: and probably is doing their own custom distro, with their own mirror</div><div>(1:50:00 PM) RP__: Well, I think its a bad move for usability</div><div>(1:50:09 PM) RP__: but I appear to be outvoted</div>
<div>(1:50:17 PM) Tartarus: We can revisit</div><div>(1:50:32 PM) Tartarus: But as an anecdote, no one's come screaming at me saying we expect a mirror for 2011.03-maint</div><div>(1:50:46 PM) RP__: It means our messages is "you can't use OE-Core unless you're an expect, pick a distro instead"</div>
<div>(1:50:46 PM) Tartarus: Since it's only supported on a defined set of combos</div><div>(1:51:07 PM) Tartarus: RP__: yes! That's what we've all been driving at I thought</div><div>(1:51:13 PM) Tartarus: You don't use oe-core by itself without another layer</div>
<div>(1:51:16 PM) fray: Thats where I thought we'd been driving as well</div><div>(1:51:26 PM) Tartarus: You use it + a distro layer + a BSP layer + ...</div><div>(1:51:27 PM) ***koen too</div><div>(1:51:31 PM) RP__: Tartarus: if that is the case why keep asking me to ensure it works? ;-)</div>
<div>(1:51:46 PM) khem: RP__: I would think adding some fall back mirrors is not a bad choice if we get notification about things coming from mirror instead of upstream</div><div>(1:51:47 PM) koen: oe-core can validate itself, but to actually be usefull you need extra layers</div>
<div>(1:51:52 PM) Tartarus: RP__: touche. We also said that it would work at the time at least sans distro, for validation</div><div>(1:51:53 PM) khem: that will address fray's concern</div><div>(1:52:29 PM) ***fray notes he's using oe-core for the development when we submits patches to oe-core..</div>
<div>(1:52:44 PM) fray: but I expect I'll need Poky/Yocto if I'm working on a distro or BSP</div><div>(1:52:45 PM) RP__: I just think having something with broken defaults is nuts. We have specific checks to check SRC_URI valitidy</div>
<div>(1:53:45 PM) Tartarus: Like I said, we can revisit this</div><div>(1:53:51 PM) Tartarus: And maybe for a maint branch we would add some mirror</div><div>(1:53:53 PM) khem: ok</div><div>(1:54:01 PM) Tartarus: But for active development, we want failures so we know there's a problem</div>
<div>(1:54:07 PM) ***khem see's RP__ 's point too</div><div>(1:54:16 PM) fray: we need to watch error reports and comments.. if people start complaining, we should reevaluate</div><div>(1:54:26 PM) RP__: Tartarus: you said we were revisiting and no further discussion. Make your mind up please</div>
<div>(1:54:49 PM) Tartarus: RP__: sorry, I mean when we have a release we can revisit if it's appropriate there</div><div>(1:55:03 PM) khem: 5 mins left</div><div>(1:55:05 PM) Tartarus: I don't think it is, but i can see a better argument there then now</div>
<div>(1:55:08 PM) Tartarus: khem: eek, thanks</div><div>(1:55:25 PM) RP__: We have people complaining now :(</div><div>(1:55:52 PM) Tartarus: Moving on while we have a few min</div><div>(1:56:02 PM) Tartarus: khem brought up the topic of people doing dev in oe.dev rather than oe-core</div>
<div>(1:56:07 PM) Tartarus: What do we want to do about that?</div><div>(1:56:21 PM) Tartarus: Make a recommendation that folks do both? Just a general reminder that oe.dev will be winding down?</div><div>(1:56:23 PM) Tartarus: something else?</div>
<div>(1:56:26 PM) khem: actually there are new devs posting new recipes or updates</div><div>(1:56:37 PM) RP__: We should be trying to ensure feature parity between oe-dev and oe-core at a minimum</div><div>(1:56:46 PM) fray: I expect it will continue, I'm just worried that when we freeze oe.dev these people are going to be "upset"</div>
<div>(1:56:52 PM) khem: so I would prefer that development to channel into new layering setup somehow</div><div>(1:57:07 PM) RP__: I think we need to put some emails out highlighting the siutation</div><div>(1:57:11 PM) fray: for the oe-core functionality I think thats reasonable.. for the others, is meta-oe at a point we should be trying to get people to push stuff there?</div>
<div>(1:57:59 PM) khem: may be a new layer</div><div>(1:58:08 PM) khem: to keep collecting updates</div><div>(1:58:24 PM) koen: looking at the size of my bblayers.conf I'd say "put stuff in meta-oe"</div><div>
(1:58:31 PM) khem: heh</div><div>(1:58:39 PM) khem: ok</div><div>(1:58:45 PM) RP__: I think this is what meta-oe was intended for</div><div>(1:58:49 PM) khem: Thats true</div><div>(1:59:02 PM) khem: OK I will send out an email</div>
<div>(1:59:25 PM) Tartarus: Sounds good</div><div>(1:59:28 PM) khem: for asking oe.dev committers to also post pull requests to meta-oe</div><div>(1:59:53 PM) RP__: khem: thanks!</div><div>(1:59:59 PM) Tartarus: OK, lets call that one done</div>
<div>(2:00:04 PM) Tartarus: Everyone got 5 more min?</div><div>(2:00:07 PM) khem: oki doki</div><div>(2:00:10 PM) ***koen does</div><div>(2:00:17 PM) ***Tartarus does</div><div>(2:00:22 PM) ***RP__ too</div><div>(2:00:23 PM) khem: me too</div>
<div>(2:00:24 PM) Tartarus: OK</div><div>(2:00:27 PM) Tartarus: So, last topic</div><div>(2:00:32 PM) Tartarus: 2011.03-maint, long term plans</div><div>(2:00:37 PM) Tartarus: koen, you brought this up, shoot</div><div>(2:01:02 PM) Tartarus: (Jefro and promoting devs to be / use the oe-users ML more for next week pls)</div>
<div>(2:01:05 PM) khem: we need to define long term may be quantitatively</div><div>(2:01:23 PM) koen: if we close .dev, we need a different strategy for the maintenance branch</div><div>(2:01:31 PM) ***Jefro noted</div><div>
(2:01:36 PM) koen: e.g. "commits need to be in oe-core/meta-oe"</div><div>(2:01:54 PM) Tartarus: koen: yes, a change of from oe.dev master to oe-core/meta-oe/relevant layer" is fine with me</div><div>(2:01:56 PM) khem: koen: yes I guess if its a common recipe in meta-oe or core</div>
<div>(2:01:58 PM) Tartarus: Anything more than that?</div><div>(2:02:06 PM) koen: not from me</div><div>(2:02:12 PM) Tartarus: OK, that's easy enough</div><div>(2:02:21 PM) Tartarus: I'll update the policy now to make that an alternative</div>
<div>(2:02:27 PM) Tartarus: to encourage folks to be pushing to the new place</div><div>(2:02:35 PM) khem: Tartarus: yes sooner this starts better it is</div><div>(2:02:38 PM) Tartarus: And not backport from there to oe.master for 2011.03 maint</div>
<div>(2:02:43 PM) khem: it can start even now</div><div>(2:02:47 PM) ***Tartarus takes the AI, will do it todayish</div><div>(2:02:54 PM) Tartarus: With that then, lets call the meeting closed</div><div>(2:02:57 PM) Tartarus: Thanks all</div>
</span><br>-- <br>Jeff Osier-Mixon <a href="http://jefro.net/blog" target="_blank">http://jefro.net/blog</a><div>Yocto Project Community Manager @Intel <a href="http://yoctoproject.org" target="_blank">http://yoctoproject.org</a></div>
<br>