<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8">
<title>#oe log</title>
<style type="text/css">
/* For the .log.html */
pre { /*line-height: 125%;*/
      white-space: pre-wrap; }
body { background: #f0f0f0; }

body .tm  { color: #007020 }                      /* time */
body .nk  { color: #062873; font-weight: bold }   /* nick, regular */
body .nka { color: #007020; font-weight: bold }  /* action nick */
body .ac  { color: #00A000 }                      /* action line */
body .hi  { color: #4070a0 }                 /* hilights */
/* Things to make particular MeetBot commands stick out */
body .topic     { color: #007020; font-weight: bold }
body .topicline { color: #000080; font-weight: bold }
body .cmd       { color: #007020; font-weight: bold }
body .cmdline  { font-weight: bold }

</style>
</head>

<body>
<pre><a name="l-1"></a><span class="tm">16:05:17</span><span class="nk"> &lt;bluelightning&gt;</span> <span class="cmd">#startmeeting</span><span class="cmdline"></span>
<a name="l-2"></a><span class="tm">16:05:17</span><span class="nk"> &lt;Crofton-bot&gt;</span> Meeting started Tue Oct  8 16:05:17 2013 UTC.  The chair is bluelightning. Information about MeetBot at http://wiki.debian.org/MeetBot.
<a name="l-3"></a><span class="tm">16:05:17</span><span class="nk"> &lt;Crofton-bot&gt;</span> Useful Commands: #action #agreed #help #info #idea #link #topic.
<a name="l-4"></a><span class="tm">16:05:17</span><span class="nk"> &lt;Crofton|work&gt;</span> then use #char rp fray to add more chairs
<a name="l-5"></a><span class="tm">16:05:28</span><span class="nk"> &lt;Crofton|work&gt;</span> er #chair
<a name="l-6"></a><span class="tm">16:05:36</span><span class="nk"> &lt;bluelightning&gt;</span> do we want everyone to be chair or just the actual chairperson?
<a name="l-7"></a><span class="tm">16:05:43</span><span class="nk"> &lt;Crofton|work&gt;</span> it helps with some of the commands
<a name="l-8"></a><span class="tm">16:06:13</span><span class="nk"> &lt;Crofton|work&gt;</span> https://wiki.debian.org/MeetBot
<a name="l-9"></a><span class="tm">16:06:16</span><span class="nk"> &lt;bluelightning&gt;</span> <span class="cmd">#chair </span><span class="cmdline">rp fray koen khem</span>
<a name="l-10"></a><span class="tm">16:06:16</span><span class="nk"> &lt;Crofton-bot&gt;</span> Current chairs: bluelightning fray khem koen rp
<a name="l-11"></a><span class="tm">16:06:22</span><span class="nk"> &lt;bluelightning&gt;</span> hmm
<a name="l-12"></a><span class="tm">16:06:29</span><span class="nk"> &lt;bluelightning&gt;</span> <span class="cmd">#chair </span><span class="cmdline">RP fray koen khem</span>
<a name="l-13"></a><span class="tm">16:06:29</span><span class="nk"> &lt;Crofton-bot&gt;</span> Current chairs: RP bluelightning fray khem koen rp
<a name="l-14"></a><span class="tm">16:06:39</span><span class="nk"> &lt;Crofton|work&gt;</span> so basically each of you can enter topics
<a name="l-15"></a><span class="tm">16:06:43</span><span class="nk"> &lt;bluelightning&gt;</span> great
<a name="l-16"></a><span class="tm">16:06:51</span><span class="nk"> &lt;Crofton|work&gt;</span> we've stumbeled on that in the past :)
<a name="l-17"></a><span class="tm">16:08:02</span><span class="nk"> &lt;bluelightning&gt;</span> so I don't think we have a formal agenda for this meeting
<a name="l-18"></a><span class="tm">16:08:17</span><span class="nk"> &lt;RP&gt;</span> no jefro? :/
<a name="l-19"></a><span class="tm">16:08:25</span><span class="nk"> &lt;bluelightning&gt;</span> it seems not
<a name="l-20"></a><span class="tm">16:08:30</span><span class="nk"> &lt;Crofton|work&gt;</span> we replaced jefro with a bot :)
<a name="l-21"></a><span class="tm">16:08:37</span><span class="nk"> &lt;fray&gt;</span> The idea is that we'd have basic status, see if there are any concerns, and open the floor for others..
<a name="l-22"></a><span class="tm">16:09:32</span><span class="nk"> &lt;bluelightning&gt;</span> ok, RP perhaps you'd like to give a quick summary of the current release status?
<a name="l-23"></a><span class="tm">16:09:42</span><span class="nk"> &lt;RP&gt;</span> Well, to summarise where we're at with OE-Core, we're coming to the end of 1.5. It should be the last -rc build today
<a name="l-24"></a><span class="tm">16:10:18</span><span class="nk"> &lt;RP&gt;</span> There were some ADT/SDK issues in the last one which have meant we need this last -rc. I did take the opportunity to merge more patches than I probably should have done, all good fixes though
<a name="l-25"></a><span class="tm">16:10:38</span><span class="nk"> &lt;RP&gt;</span> master and dora are likely to start diverging now
<a name="l-26"></a><span class="tm">16:11:30</span><span class="nk"> &lt;RP&gt;</span> Happy to answer questions if anyone has any
<a name="l-27"></a><span class="tm">16:12:24</span><span class="nk"> &lt;Crofton|work&gt;</span> How is planning for the next dev cycle going?
<a name="l-28"></a><span class="tm">16:12:37</span><span class="nk"> &lt;fray&gt;</span> I think it's just starting..
<a name="l-29"></a><span class="tm">16:12:57</span><span class="nk"> &lt;fray&gt;</span> so input, working groups, etc... it's a good time for peoople to start thinking (and doing) now
<a name="l-30"></a><span class="tm">16:13:04</span><span class="nk"> &lt;RP&gt;</span> <span class="hi">Crofton|work:</span> Its a bit late. We have a rough idea of the themes
<a name="l-31"></a><span class="tm">16:13:23</span><span class="nk"> &lt;Crofton|work&gt;</span> such as?
<a name="l-32"></a><span class="tm">16:13:24</span><span class="nk"> &lt;RP&gt;</span> but basically if anyone has things they'd like to see in the next cycle get them in bugzilla yesterday
<a name="l-33"></a><span class="tm">16:14:03</span><span class="nk"> &lt;RP&gt;</span> <span class="hi">Crofton|work:</span> Continue to extend the runtime QA tests, integrate ptest into those QA tests, also look at real hardware testing
<a name="l-34"></a><span class="tm">16:14:12</span><span class="nk"> &lt;Crofton|work&gt;</span> nice
<a name="l-35"></a><span class="tm">16:14:19</span><span class="nk"> &lt;bluelightning&gt;</span> also non-runtime tests (tests of the build system itself)
<a name="l-36"></a><span class="tm">16:14:27</span><span class="nk"> &lt;fray&gt;</span> I'll be pushing my own agenda a bit.. more on the deployment side of the world..
<a name="l-37"></a><span class="tm">16:14:53</span><span class="nk"> &lt;fray&gt;</span> package feeds, runtime package upgrades, spdx generation/processing, etc...
<a name="l-38"></a><span class="tm">16:14:55</span><span class="nk"> &lt;RP&gt;</span> yes, wic came in late but can be thought of as beta and something which will develope
<a name="l-39"></a><span class="tm">16:15:17</span><span class="nk"> &lt;RP&gt;</span> and webhob will land in 1.6 with some special released standalone meanwhile
<a name="l-40"></a><span class="tm">16:17:05</span><span class="nk"> &lt;fray&gt;</span> speaking of SPDX, I'll be giving a talk about the spdx/Yocto Project (oe-core) integration at ELC-E in a couple weeks..  the topic is basically the spdx.bbclass that went in and where we think it's going to go...
<a name="l-41"></a><span class="tm">16:17:21</span><span class="nk"> &lt;fray&gt;</span> (hint we want end-to-end license/source/binary traceability)
<a name="l-42"></a><span class="tm">16:18:57</span><span class="nk"> &lt;RP&gt;</span> <span class="hi">fray:</span> for a second I read that as "we want to end"
<a name="l-43"></a><span class="tm">16:19:10</span><span class="nk"> &lt;fray&gt;</span> ha
<a name="l-44"></a><span class="tm">16:19:52</span><span class="nk"> &lt;Crofton|work&gt;</span> btw you forgot to say #topic RP review blah blah :)
<a name="l-45"></a><span class="tm">16:21:24</span><span class="nk"> &lt;RP&gt;</span> <span class="hi">bluelightning:</span> I'm kind of assuming you're chairing FWIW
<a name="l-46"></a><span class="tm">16:21:38</span><span class="nk"> &lt;fray&gt;</span> lol..
<a name="l-47"></a><span class="tm">16:21:38</span><span class="nk"> &lt;bluelightning&gt;</span> I guess I'm volunteered then ;)
<a name="l-48"></a><span class="tm">16:22:09</span><span class="nk"> &lt;Crofton|work&gt;</span> can we move to concerns?
<a name="l-49"></a><span class="tm">16:22:17</span><span class="nk"> &lt;bluelightning&gt;</span> yes let's do that
<a name="l-50"></a><span class="tm">16:22:29</span><span class="nk"> &lt;bluelightning&gt;</span> <span class="topic">#topic </span><span class="topicline">community concerns</span>
<a name="l-51"></a><span class="tm">16:23:04</span><span class="nk"> &lt;Crofton|work&gt;</span> It seems like we are very good at building images for bits of hardware,
<a name="l-52"></a><span class="tm">16:23:11</span><span class="nk"> &lt;bluelightning&gt;</span> does anyone have anything they'd like to raise?
<a name="l-53"></a><span class="tm">16:23:16</span><span class="nk"> &lt;Crofton|work&gt;</span> but not so good at fixing run time issues
<a name="l-54"></a><span class="tm">16:23:41</span><span class="nk"> &lt;fray&gt;</span> I think runtime issues (i.e. the package upgrades I mentioned earlier) are things we need to start spending more time on..
<a name="l-55"></a><span class="tm">16:23:54</span><span class="nk"> &lt;fray&gt;</span> we're finding and fixing the bugs I've seen.. but I know testing is far from complete.
<a name="l-56"></a><span class="tm">16:23:59</span><span class="nk"> &lt;bluelightning&gt;</span> yes, I think it's fair to say we haven't concentrated enough on improving and maintaining runtime
<a name="l-57"></a><span class="tm">16:24:00</span><span class="nk"> &lt;Crofton|work&gt;</span> basically, I am thinking about the problem of end users getting binary images for their hardware
<a name="l-58"></a><span class="tm">16:24:10</span><span class="nk"> &lt;Crofton|work&gt;</span> I realize this is not directly an OE issue
<a name="l-59"></a><span class="tm">16:24:14</span><span class="nk"> &lt;fray&gt;</span> ahh thats a little different then
<a name="l-60"></a><span class="tm">16:24:16</span><span class="nk"> &lt;Crofton|work&gt;</span> more for distros
<a name="l-61"></a><span class="tm">16:24:37</span><span class="nk"> &lt;Crofton|work&gt;</span> but, I think it is important enough we need to think about it
<a name="l-62"></a><span class="tm">16:24:43</span><span class="nk"> &lt;bluelightning&gt;</span> if it's giving distros tools that help them do their jobs, then it is within our remit
<a name="l-63"></a><span class="tm">16:24:52</span><span class="nk"> &lt;fray&gt;</span> yup
<a name="l-64"></a><span class="tm">16:24:57</span><span class="nk"> &lt;Crofton|work&gt;</span> distros should not be fixing up stupid metadata issues
<a name="l-65"></a><span class="tm">16:25:21</span><span class="nk"> &lt;RP&gt;</span> <span class="hi">Crofton|work:</span> can you be more specific about the problem? Are distros having to fix stupid metadata issues?
<a name="l-66"></a><span class="tm">16:25:23</span><span class="nk"> &lt;Crofton|work&gt;</span> I jsut wanted to get this out there for people to be thinking about
<a name="l-67"></a><span class="tm">16:25:43</span><span class="nk"> &lt;Crofton|work&gt;</span> well, I had to listen to some guy praising a linaro rootfs becuase it just worked
<a name="l-68"></a><span class="tm">16:26:08</span><span class="nk"> &lt;Crofton|work&gt;</span> and I am thinking, what aren't we doing to be in that position
<a name="l-69"></a><span class="tm">16:26:35</span><span class="nk"> &lt;bluelightning&gt;</span> <span class="hi">Crofton|work:</span> I think it's worth mentioning our additional runtime testing should help avoid errors during boot and other regressions creeping in as they have during previous development cycles
<a name="l-70"></a><span class="tm">16:27:05</span><span class="nk"> &lt;RP&gt;</span> <span class="hi">Crofton|work:</span> A lot of what happens in the core is not end user enabling. It turns out that is rather specific to particular projects and products :/
<a name="l-71"></a><span class="tm">16:27:05</span><span class="nk"> &lt;Crofton|work&gt;</span> and I'd like to see the hw vendors caring more about stuff working on their hw etc
<a name="l-72"></a><span class="tm">16:27:08</span><span class="nk"> &lt;rburton&gt;</span> i have previously thought that QA should be testing the upgrade path for packages to ensure that week N can upgrade to N+1, for example.
<a name="l-73"></a><span class="tm">16:27:14</span><span class="nk"> &lt;bluelightning&gt;</span> that said, we now need to look at expanding those runtime tests in the forthcoming cycle, including adding tests in other layers in the OE ecosystem (which is now possible)
<a name="l-74"></a><span class="tm">16:27:26</span><span class="nk"> &lt;fray&gt;</span> Crofton|work I do hear people talking about the need for 'validation' images.. an image known to work (or at least with a known set of problems) for hardware bring-up, and early application development..
<a name="l-75"></a><span class="tm">16:27:29</span><span class="nk"> &lt;RP&gt;</span> <span class="hi">Crofton|work:</span> Its a question of *what* working? A webserver? A GL app? HTML page?
<a name="l-76"></a><span class="tm">16:27:40</span><span class="nk"> &lt;Crofton|work&gt;</span> sure
<a name="l-77"></a><span class="tm">16:27:41</span><span class="nk"> &lt;fray&gt;</span> rburton yes
<a name="l-78"></a><span class="tm">16:27:54</span><span class="nk"> &lt;Crofton|work&gt;</span> these are things we need to care about
<a name="l-79"></a><span class="tm">16:27:57</span><span class="nk"> &lt;RP&gt;</span> <span class="hi">rburton:</span> we should automated testing that...
<a name="l-80"></a><span class="tm">16:28:14</span><span class="nk"> &lt;rburton&gt;</span> <span class="hi">rp:</span> sure, it's a "trivial" thing to do.
<a name="l-81"></a><span class="tm">16:28:35</span><span class="nk"> &lt;RP&gt;</span> <span class="hi">rburton:</span> perhaps file an ehancement bug?
<a name="l-82"></a><span class="tm">16:28:41</span><span class="nk"> &lt;rburton&gt;</span> <span class="hi">rp:</span> aye
<a name="l-83"></a><span class="tm">16:28:53</span><span class="nk"> &lt;bluelightning&gt;</span> I thought there was one open for that already
<a name="l-84"></a><span class="tm">16:29:16</span><span class="nk"> &lt;rburton&gt;</span> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4304
<a name="l-85"></a><span class="tm">16:29:18</span><span class="nk"> &lt;rburton&gt;</span> yes, i filed it already :)
<a name="l-86"></a><span class="tm">16:29:24</span><span class="nk"> &lt;RP&gt;</span> There is a serious point here, only today I heard that people are struggling to figure out what test cases are needed...
<a name="l-87"></a><span class="tm">16:29:26</span><span class="nk"> &lt;bluelightning&gt;</span> <span class="hi">rburton:</span> you filed it, do I get a cookie? ;)
<a name="l-88"></a><span class="tm">16:30:00</span><span class="nk"> &lt;rburton&gt;</span> its marked as Future, which is why it "disappeared"
<a name="l-89"></a><span class="tm">16:30:20</span><span class="nk"> &lt;RP&gt;</span> <span class="hi">rburton:</span> Its no longer marked as future ;-)
<a name="l-90"></a><span class="tm">16:30:34</span><span class="nk"> &lt;bluelightning&gt;</span> <span class="hi">RP:</span> to give a proper answer to that question we would need to define the functionality we expect to provide, so we can verify it works...
<a name="l-91"></a><span class="tm">16:31:00</span><span class="nk"> &lt;bluelightning&gt;</span> obviously each time we add a new feature we know we ought to have a test for it
<a name="l-92"></a><span class="tm">16:31:04</span><span class="nk"> &lt;fray&gt;</span> I think that is certainly one of the trickier aspects of any open source distro.. defining what should work and verification..
<a name="l-93"></a><span class="tm">16:31:08</span><span class="nk"> &lt;RP&gt;</span> <span class="hi">bluelightning:</span> agreed, we're just struggling to have all the right information with the right people though
<a name="l-94"></a><span class="tm">16:31:16</span><span class="nk"> &lt;fray&gt;</span> yup to both
<a name="l-95"></a><span class="tm">16:32:25</span><span class="nk"> &lt;RP&gt;</span> I'd also add that whilst I've done a lot to drive some of these things in the past I'm not scaling well so I need people to help with it...
<a name="l-96"></a><span class="tm">16:33:01 </span><span class="nka">* RP</span> <span class="ac">also notes that he really should stop looking at C++ bugs as it makes his head hurt</span>
<a name="l-97"></a><span class="tm">16:33:13</span><span class="nk"> &lt;Crofton|work&gt;</span> we all mail RP sets of hw we want to work well and he tests!
<a name="l-98"></a><span class="tm">16:33:43</span><span class="nk"> &lt;fray&gt;</span> next update RP cloning machine..
<a name="l-99"></a><span class="tm">16:33:44</span><span class="nk"> &lt;bluelightning&gt;</span> I'd like to hope that with the added focus on automated testing we'd get some more direct contributions from QA engineers in the various organisations
<a name="l-100"></a><span class="tm">16:34:01</span><span class="nk"> &lt;RP&gt;</span> <span class="hi">Crofton|work:</span> I can then forward them on to you and delegate ;-)
<a name="l-101"></a><span class="tm">16:34:18</span><span class="nk"> &lt;RP&gt;</span> and from other projects
<a name="l-102"></a><span class="tm">16:34:38</span><span class="nk"> &lt;RP&gt;</span> i.e. if they know we can test and find regressions, perhaps we'll get more users/contributores
<a name="l-103"></a><span class="tm">16:35:55</span><span class="nk"> &lt;bluelightning&gt;</span> so, anything else people would like to talk about?
<a name="l-104"></a><span class="tm">16:36:08</span><span class="nk"> &lt;Crofton|work&gt;</span> Yep
<a name="l-105"></a><span class="tm">16:36:32</span><span class="nk"> &lt;Crofton|work&gt;</span> At the GNU Radio Conference last week we talked about moving gnuradio and uhd to "meta-sdr"
<a name="l-106"></a><span class="tm">16:36:44</span><span class="nk"> &lt;RP&gt;</span> The feedback has always been people want to be more involved with the TSC so it would be good to see more people talking here :/
<a name="l-107"></a><span class="tm">16:36:52</span><span class="nk"> &lt;Crofton|work&gt;</span> I suspect some other stuff will find a home there, but not amateur radio stuff
<a name="l-108"></a><span class="tm">16:37:11</span><span class="nk"> &lt;bluelightning&gt;</span> <span class="hi">Crofton|work:</span> sounds like a reasonable move to me
<a name="l-109"></a><span class="tm">16:37:35</span><span class="nk"> &lt;Crofton|work&gt;</span> I'm going to send something to the oe list, but was wondering if we had guildeines in place?
<a name="l-110"></a><span class="tm">16:37:52</span><span class="nk"> &lt;fray&gt;</span> for the meta-openembedded stuff, I think we've been pretty fluid..
<a name="l-111"></a><span class="tm">16:37:59</span><span class="nk"> &lt;Crofton|work&gt;</span> that is what I think
<a name="l-112"></a><span class="tm">16:38:01</span><span class="nk"> &lt;RP&gt;</span> <span class="hi">Crofton|work:</span> its usually for discussion between the layer maintainers
<a name="l-113"></a><span class="tm">16:38:02</span><span class="nk"> &lt;fray&gt;</span> new layers/divisions get created when necessary..
<a name="l-114"></a><span class="tm">16:38:17</span><span class="nk"> &lt;bluelightning&gt;</span> well, AIUI what we care about when it comes to creating new layers be they in meta-openembedded or outside of it is that there's a maintainer and there's some level of maintenance of the layer
<a name="l-115"></a><span class="tm">16:38:46</span><span class="nk"> &lt;Crofton|work&gt;</span> I was going o make it inside meta-oe, since it will retain a dependency on meta-oe I suspect
<a name="l-116"></a><span class="tm">16:38:47</span><span class="nk"> &lt;fray&gt;</span> yup.. someone has to step up..
<a name="l-117"></a><span class="tm">16:39:01</span><span class="nk"> &lt;Crofton|work&gt;</span> we just want to be able to mess around with it as a group
<a name="l-118"></a><span class="tm">16:39:13</span><span class="nk"> &lt;bluelightning&gt;</span> fair enough
<a name="l-119"></a><span class="tm">16:39:14</span><span class="nk"> &lt;bluelightning&gt;</span> I'd suggest RFCing it as you've proposed
<a name="l-120"></a><span class="tm">16:39:17</span><span class="nk"> &lt;Crofton|work&gt;</span> thanks
<a name="l-121"></a><span class="tm">16:39:52</span><span class="nk"> &lt;Crofton|work&gt;</span> I need to run, when you are done do #endmeeting and I'll send the output to jefro
<a name="l-122"></a><span class="tm">16:39:59</span><span class="nk"> &lt;bluelightning&gt;</span> speaking of layers, there are still a huge number of unindexed layers on github etc., and more are added weekly
<a name="l-123"></a><span class="tm">16:40:17</span><span class="nk"> &lt;Crofton|work&gt;</span> use topic :)
<a name="l-124"></a><span class="tm">16:40:22</span><span class="nk"> &lt;bluelightning&gt;</span> <span class="topic">#topic </span><span class="topicline">layers</span>
<a name="l-125"></a><span class="tm">16:40:41</span><span class="nk"> &lt;RP&gt;</span> Personally, I'd really like people to consider sharing the layers on git.oe.org or git.yp.org
<a name="l-126"></a><span class="tm">16:40:50</span><span class="nk"> &lt;bluelightning&gt;</span> if you're maintaining a layer that others might find useful please submit it at http://layers.openembedded.org/
<a name="l-127"></a><span class="tm">16:40:59</span><span class="nk"> &lt;RP&gt;</span> just so there is some standard place people can look at...
<a name="l-128"></a><span class="tm">16:41:07</span><span class="nk"> &lt;RP&gt;</span> (as well as the index)
<a name="l-129"></a><span class="tm">16:41:51</span><span class="nk"> &lt;bluelightning&gt;</span> yes, it's worth pointing out that yoctoproject.org and openembedded.org can both provide hosting for maintained layers
<a name="l-130"></a><span class="tm">16:42:57</span><span class="nk"> &lt;Crofton|work&gt;</span> people really like github etc
<a name="l-131"></a><span class="tm">16:43:20</span><span class="nk"> &lt;RP&gt;</span> <span class="hi">Crofton|work:</span> its good for some things, less good for others
<a name="l-132"></a><span class="tm">16:43:23</span><span class="nk"> &lt;fray&gt;</span> Crofton|work, for people posting there or elsewhere, the layer index is advisable...
<a name="l-133"></a><span class="tm">16:43:47</span><span class="nk"> &lt;bluelightning&gt;</span> yep, as far as the layer index is concerned, it doesn't matter where it is as long as it's publicly accessible
<a name="l-134"></a><span class="tm">16:43:48</span><span class="nk"> &lt;Crofton|work&gt;</span> right the layerindex is awesome
<a name="l-135"></a><span class="tm">16:43:53</span><span class="nk"> &lt;fray&gt;</span> my only issue w/ github (and other places) is that it's harder to find layers that are -maintained- because you don't really know the commitment level of the people working on the layer
<a name="l-136"></a><span class="tm">16:43:56</span><span class="nk"> &lt;bluelightning&gt;</span> it's not even mandatory that it has a web interface
<a name="l-137"></a><span class="tm">16:44:07</span><span class="nk"> &lt;Crofton|work&gt;</span> we need to focus our efforts on indexing
<a name="l-138"></a><span class="tm">16:44:24</span><span class="nk"> &lt;bluelightning&gt;</span> the layer index does report "last updated" information
<a name="l-139"></a><span class="tm">16:44:42</span><span class="nk"> &lt;bluelightning&gt;</span> we could always collect/analyse more if desirable
<a name="l-140"></a><span class="tm">16:46:24</span><span class="nk"> &lt;bluelightning&gt;</span> I'd almost say it's not mandatory for a layer to be *heavily* maintained to be in the layer index either; if it's there people can find it and contribute to it
<a name="l-141"></a><span class="tm">16:47:11</span><span class="nk"> &lt;Crofton|work&gt;</span> right
<a name="l-142"></a><span class="tm">16:47:23</span><span class="nk"> &lt;bluelightning&gt;</span> not having people rewrite the same recipes was a key goal for setting it up
<a name="l-143"></a><span class="tm">16:48:07</span><span class="nk"> &lt;RP&gt;</span> I think my worry is that OE is seen as this fragmented and inconsistent mess :/
<a name="l-144"></a><span class="tm">16:48:28</span><span class="nk"> &lt;RP&gt;</span> the index helps but I do think a bit more standardisation would also help...
<a name="l-145"></a><span class="tm">16:48:32</span><span class="nk"> &lt;bluelightning&gt;</span> I haven't heard that comment a lot, FWIW
<a name="l-146"></a><span class="tm">16:48:40</span><span class="nk"> &lt;bluelightning&gt;</span> but it is hard to get started
<a name="l-147"></a><span class="tm">16:49:13</span><span class="nk"> &lt;Crofton|work&gt;</span> well, we need to work out from oe-core to improve layers
<a name="l-148"></a><span class="tm">16:49:26</span><span class="nk"> &lt;bluelightning&gt;</span> there's certainly more we could do with analysing (and testing, with some community help) of layers outside OE-Core
<a name="l-149"></a><span class="tm">16:49:40</span><span class="nk"> &lt;Crofton|work&gt;</span> we can not digest everything at once, but we can work with critical layer s to improve them
<a name="l-150"></a><span class="tm">16:50:16</span><span class="nk"> &lt;RP&gt;</span> I'm hoping if we get more good testing in the core, this will spread...
<a name="l-151"></a><span class="tm">16:50:30</span><span class="nk"> &lt;RP&gt;</span> and with better tests, quality in other layers may improve
<a name="l-152"></a><span class="tm">16:51:21</span><span class="nk"> &lt;bluelightning&gt;</span> FWIW, I think this cycle has already seen quite significant quality improvements in meta-oe thanks to JaMa's autobuilder testing/fixing
<a name="l-153"></a><span class="tm">16:51:31</span><span class="nk"> &lt;JaMa&gt;</span> sorry for late comment, I think that for QA and upgrade-path issues I should finish https://bugzilla.yoctoproject.org/show_bug.cgi?id=3505 soon
<a name="l-154"></a><span class="tm">16:51:50</span><span class="nk"> &lt;bluelightning&gt;</span> ah yes, good point
<a name="l-155"></a><span class="tm">16:51:59</span><span class="nk"> &lt;fray&gt;</span> JaMa, excellent..
<a name="l-156"></a><span class="tm">16:52:58</span><span class="nk"> &lt;bluelightning&gt;</span> ok, 8 mins left - anything else folks would like to discuss?
<a name="l-157"></a><span class="tm">16:53:21</span><span class="nk"> &lt;RP&gt;</span> <span class="hi">JaMa:</span> yes, that will help too...
<a name="l-158"></a><span class="tm">16:56:27</span><span class="nk"> &lt;fray&gt;</span> so I see 4 minutes or so till the hour..
<a name="l-159"></a><span class="tm">16:56:33</span><span class="nk"> &lt;bluelightning&gt;</span> yep
<a name="l-160"></a><span class="tm">16:56:42</span><span class="nk"> &lt;fray&gt;</span> any thing else, otherwise.. we may have run out of topics..
<a name="l-161"></a><span class="tm">16:56:52</span><span class="nk"> &lt;fray&gt;</span> Next meeting would be first or second week of Nov.. right?
<a name="l-162"></a><span class="tm">16:56:57</span><span class="nk"> &lt;bluelightning&gt;</span> <span class="topic">#topic </span><span class="topicline">next meeting</span>
<a name="l-163"></a><span class="tm">16:57:05</span><span class="nk"> &lt;Crofton|work&gt;</span> yay bluelightning
<a name="l-164"></a><span class="tm">16:57:06</span><span class="nk"> &lt;fray&gt;</span> I think Nov 5th will be the next meeting
<a name="l-165"></a><span class="tm">16:57:20</span><span class="nk"> &lt;bluelightning&gt;</span> so the only thing I can think of is nominate a person to send out the next meeting invite
<a name="l-166"></a><span class="tm">16:57:43</span><span class="nk"> &lt;Crofton|work&gt;</span> bluelightning, try recording that via the #action command
<a name="l-167"></a><span class="tm">16:57:43</span><span class="nk"> &lt;bluelightning&gt;</span> I can do it, but someone needs to actually do it
<a name="l-168"></a><span class="tm">16:58:14</span><span class="nk"> &lt;bluelightning&gt;</span> <span class="cmd">#action </span><span class="cmdline">bluelightning send out meeting invite for nov 5th</span>
<a name="l-169"></a><span class="tm">16:58:24</span><span class="nk"> &lt;bluelightning&gt;</span> presumably that did something...
<a name="l-170"></a><span class="tm">16:59:07</span><span class="nk"> &lt;Crofton|work&gt;</span> we'll see
<a name="l-171"></a><span class="tm">16:59:23</span><span class="nk"> &lt;bluelightning&gt;</span> ok, if nothing further, I guess we can call it a meeting?
<a name="l-172"></a><span class="tm">16:59:30</span><span class="nk"> &lt;fray&gt;</span> works for me!
<a name="l-173"></a><span class="tm">16:59:31</span><span class="nk"> &lt;fray&gt;</span> thanks!
<a name="l-174"></a><span class="tm">16:59:36</span><span class="nk"> &lt;bluelightning&gt;</span> thanks everyone
<a name="l-175"></a><span class="tm">16:59:41</span><span class="nk"> &lt;Crofton|work&gt;</span> type #endmeeting
<a name="l-176"></a><span class="tm">16:59:41</span><span class="nk"> &lt;RP&gt;</span> <span class="hi">bluelightning:</span> sounds good, thanks
<a name="l-177"></a><span class="tm">16:59:42</span><span class="nk"> &lt;bluelightning&gt;</span> <span class="cmd">#endmeeting</span><span class="cmdline"></span></pre>
</body></html>