Minutes

Tue Oct 8 17:01:41 UTC 2013

Here you go
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/tsc/attachments/20131008/845621d9/attachment-0002.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/tsc/attachments/20131008/845621d9/attachment-0003.html>
-------------- next part --------------
16:05:17 <bluelightning> #startmeeting
16:05:17 <Crofton-bot> Meeting started Tue Oct  8 16:05:17 2013 UTC.  The chair is bluelightning. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:17 <Crofton-bot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:05:17 <Crofton|work> then use #char rp fray to add more chairs
16:05:28 <Crofton|work> er #chair
16:05:36 <bluelightning> do we want everyone to be chair or just the actual chairperson?
16:05:43 <Crofton|work> it helps with some of the commands
16:06:13 <Crofton|work> https://wiki.debian.org/MeetBot
16:06:16 <bluelightning> #chair rp fray koen khem
16:06:16 <Crofton-bot> Current chairs: bluelightning fray khem koen rp
16:06:22 <bluelightning> hmm
16:06:29 <bluelightning> #chair RP fray koen khem
16:06:29 <Crofton-bot> Current chairs: RP bluelightning fray khem koen rp
16:06:39 <Crofton|work> so basically each of you can enter topics
16:06:43 <bluelightning> great
16:06:51 <Crofton|work> we've stumbeled on that in the past :)
16:08:02 <bluelightning> so I don't think we have a formal agenda for this meeting
16:08:17 <RP> no jefro? :/
16:08:25 <bluelightning> it seems not
16:08:30 <Crofton|work> we replaced jefro with a bot :)
16:08:37 <fray> The idea is that we'd have basic status, see if there are any concerns, and open the floor for others..
16:09:32 <bluelightning> ok, RP perhaps you'd like to give a quick summary of the current release status?
16:09:42 <RP> 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
16:10:18 <RP> 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
16:10:38 <RP> master and dora are likely to start diverging now
16:11:30 <RP> Happy to answer questions if anyone has any
16:12:24 <Crofton|work> How is planning for the next dev cycle going?
16:12:37 <fray> I think it's just starting..
16:12:57 <fray> so input, working groups, etc... it's a good time for peoople to start thinking (and doing) now
16:13:04 <RP> Crofton|work: Its a bit late. We have a rough idea of the themes
16:13:23 <Crofton|work> such as?
16:13:24 <RP> but basically if anyone has things they'd like to see in the next cycle get them in bugzilla yesterday
16:14:03 <RP> Crofton|work: Continue to extend the runtime QA tests, integrate ptest into those QA tests, also look at real hardware testing
16:14:12 <Crofton|work> nice
16:14:19 <bluelightning> also non-runtime tests (tests of the build system itself)
16:14:27 <fray> I'll be pushing my own agenda a bit.. more on the deployment side of the world..
16:14:53 <fray> package feeds, runtime package upgrades, spdx generation/processing, etc...
16:14:55 <RP> yes, wic came in late but can be thought of as beta and something which will develope
16:15:17 <RP> and webhob will land in 1.6 with some special released standalone meanwhile
16:17:05 <fray> 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...
16:17:21 <fray> (hint we want end-to-end license/source/binary traceability)
16:18:57 <RP> fray: for a second I read that as "we want to end"
16:19:10 <fray> ha
16:19:52 <Crofton|work> btw you forgot to say #topic RP review blah blah :)
16:21:24 <RP> bluelightning: I'm kind of assuming you're chairing FWIW
16:21:38 <fray> lol..
16:21:38 <bluelightning> I guess I'm volunteered then ;)
16:22:09 <Crofton|work> can we move to concerns?
16:22:17 <bluelightning> yes let's do that
16:22:29 <bluelightning> #topic community concerns
16:23:04 <Crofton|work> It seems like we are very good at building images for bits of hardware,
16:23:11 <bluelightning> does anyone have anything they'd like to raise?
16:23:16 <Crofton|work> but not so good at fixing run time issues
16:23:41 <fray> I think runtime issues (i.e. the package upgrades I mentioned earlier) are things we need to start spending more time on..
16:23:54 <fray> we're finding and fixing the bugs I've seen.. but I know testing is far from complete.
16:23:59 <bluelightning> yes, I think it's fair to say we haven't concentrated enough on improving and maintaining runtime
16:24:00 <Crofton|work> basically, I am thinking about the problem of end users getting binary images for their hardware
16:24:10 <Crofton|work> I realize this is not directly an OE issue
16:24:14 <fray> ahh thats a little different then
16:24:16 <Crofton|work> more for distros
16:24:37 <Crofton|work> but, I think it is important enough we need to think about it
16:24:43 <bluelightning> if it's giving distros tools that help them do their jobs, then it is within our remit
16:24:52 <fray> yup
16:24:57 <Crofton|work> distros should not be fixing up stupid metadata issues
16:25:21 <RP> Crofton|work: can you be more specific about the problem? Are distros having to fix stupid metadata issues?
16:25:23 <Crofton|work> I jsut wanted to get this out there for people to be thinking about
16:25:43 <Crofton|work> well, I had to listen to some guy praising a linaro rootfs becuase it just worked
16:26:08 <Crofton|work> and I am thinking, what aren't we doing to be in that position
16:26:35 <bluelightning> Crofton|work: 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
16:27:05 <RP> Crofton|work: 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 :/
16:27:05 <Crofton|work> and I'd like to see the hw vendors caring more about stuff working on their hw etc
16:27:08 <rburton> 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.
16:27:14 <bluelightning> 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)
16:27:26 <fray> 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..
16:27:29 <RP> Crofton|work: Its a question of *what* working? A webserver? A GL app? HTML page?
16:27:40 <Crofton|work> sure
16:27:41 <fray> rburton yes
16:27:54 <Crofton|work> these are things we need to care about
16:27:57 <RP> rburton: we should automated testing that...
16:28:14 <rburton> rp: sure, it's a "trivial" thing to do.
16:28:35 <RP> rburton: perhaps file an ehancement bug?
16:28:41 <rburton> rp: aye
16:28:53 <bluelightning> I thought there was one open for that already
16:29:16 <rburton> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4304
16:29:18 <rburton> yes, i filed it already :)
16:29:24 <RP> There is a serious point here, only today I heard that people are struggling to figure out what test cases are needed...
16:29:26 <bluelightning> rburton: you filed it, do I get a cookie? ;)
16:30:00 <rburton> its marked as Future, which is why it "disappeared"
16:30:20 <RP> rburton: Its no longer marked as future ;-)
16:30:34 <bluelightning> RP: 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...
16:31:00 <bluelightning> obviously each time we add a new feature we know we ought to have a test for it
16:31:04 <fray> I think that is certainly one of the trickier aspects of any open source distro.. defining what should work and verification..
16:31:08 <RP> bluelightning: agreed, we're just struggling to have all the right information with the right people though
16:31:16 <fray> yup to both
16:32:25 <RP> 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...
16:33:01 * RP also notes that he really should stop looking at C++ bugs as it makes his head hurt
16:33:13 <Crofton|work> we all mail RP sets of hw we want to work well and he tests!
16:33:43 <fray> next update RP cloning machine..
16:33:44 <bluelightning> 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
16:34:01 <RP> Crofton|work: I can then forward them on to you and delegate ;-)
16:34:18 <RP> and from other projects
16:34:38 <RP> i.e. if they know we can test and find regressions, perhaps we'll get more users/contributores
16:35:55 <bluelightning> so, anything else people would like to talk about?
16:36:08 <Crofton|work> Yep
16:36:32 <Crofton|work> At the GNU Radio Conference last week we talked about moving gnuradio and uhd to "meta-sdr"
16:36:44 <RP> 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 :/
16:36:52 <Crofton|work> I suspect some other stuff will find a home there, but not amateur radio stuff
16:37:11 <bluelightning> Crofton|work: sounds like a reasonable move to me
16:37:35 <Crofton|work> I'm going to send something to the oe list, but was wondering if we had guildeines in place?
16:37:52 <fray> for the meta-openembedded stuff, I think we've been pretty fluid..
16:37:59 <Crofton|work> that is what I think
16:38:01 <RP> Crofton|work: its usually for discussion between the layer maintainers
16:38:02 <fray> new layers/divisions get created when necessary..
16:38:17 <bluelightning> 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
16:38:46 <Crofton|work> I was going o make it inside meta-oe, since it will retain a dependency on meta-oe I suspect
16:38:47 <fray> yup.. someone has to step up..
16:39:01 <Crofton|work> we just want to be able to mess around with it as a group
16:39:13 <bluelightning> fair enough
16:39:14 <bluelightning> I'd suggest RFCing it as you've proposed
16:39:17 <Crofton|work> thanks
16:39:52 <Crofton|work> I need to run, when you are done do #endmeeting and I'll send the output to jefro
16:39:59 <bluelightning> speaking of layers, there are still a huge number of unindexed layers on github etc., and more are added weekly
16:40:17 <Crofton|work> use topic :)
16:40:22 <bluelightning> #topic layers
16:40:41 <RP> Personally, I'd really like people to consider sharing the layers on git.oe.org or git.yp.org
16:40:50 <bluelightning> if you're maintaining a layer that others might find useful please submit it at http://layers.openembedded.org/
16:40:59 <RP> just so there is some standard place people can look at...
16:41:07 <RP> (as well as the index)
16:41:51 <bluelightning> yes, it's worth pointing out that yoctoproject.org and openembedded.org can both provide hosting for maintained layers
16:42:57 <Crofton|work> people really like github etc
16:43:20 <RP> Crofton|work: its good for some things, less good for others
16:43:23 <fray> Crofton|work, for people posting there or elsewhere, the layer index is advisable...
16:43:47 <bluelightning> yep, as far as the layer index is concerned, it doesn't matter where it is as long as it's publicly accessible
16:43:48 <Crofton|work> right the layerindex is awesome
16:43:53 <fray> 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
16:43:56 <bluelightning> it's not even mandatory that it has a web interface
16:44:07 <Crofton|work> we need to focus our efforts on indexing
16:44:24 <bluelightning> the layer index does report "last updated" information
16:44:42 <bluelightning> we could always collect/analyse more if desirable
16:46:24 <bluelightning> 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
16:47:11 <Crofton|work> right
16:47:23 <bluelightning> not having people rewrite the same recipes was a key goal for setting it up
16:48:07 <RP> I think my worry is that OE is seen as this fragmented and inconsistent mess :/
16:48:28 <RP> the index helps but I do think a bit more standardisation would also help...
16:48:32 <bluelightning> I haven't heard that comment a lot, FWIW
16:48:40 <bluelightning> but it is hard to get started
16:49:13 <Crofton|work> well, we need to work out from oe-core to improve layers
16:49:26 <bluelightning> there's certainly more we could do with analysing (and testing, with some community help) of layers outside OE-Core
16:49:40 <Crofton|work> we can not digest everything at once, but we can work with critical layer s to improve them
16:50:16 <RP> I'm hoping if we get more good testing in the core, this will spread...
16:50:30 <RP> and with better tests, quality in other layers may improve
16:51:21 <bluelightning> FWIW, I think this cycle has already seen quite significant quality improvements in meta-oe thanks to JaMa's autobuilder testing/fixing
16:51:31 <JaMa> 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
16:51:50 <bluelightning> ah yes, good point
16:51:59 <fray> JaMa, excellent..
16:52:58 <bluelightning> ok, 8 mins left - anything else folks would like to discuss?
16:53:21 <RP> JaMa: yes, that will help too...
16:56:27 <fray> so I see 4 minutes or so till the hour..
16:56:33 <bluelightning> yep
16:56:42 <fray> any thing else, otherwise.. we may have run out of topics..
16:56:52 <fray> Next meeting would be first or second week of Nov.. right?
16:56:57 <bluelightning> #topic next meeting
16:57:05 <Crofton|work> yay bluelightning
16:57:06 <fray> I think Nov 5th will be the next meeting
16:57:20 <bluelightning> so the only thing I can think of is nominate a person to send out the next meeting invite
16:57:43 <Crofton|work> bluelightning, try recording that via the #action command
16:57:43 <bluelightning> I can do it, but someone needs to actually do it
16:58:14 <bluelightning> #action bluelightning send out meeting invite for nov 5th
16:58:24 <bluelightning> presumably that did something...
16:59:07 <Crofton|work> we'll see
16:59:23 <bluelightning> ok, if nothing further, I guess we can call it a meeting?
16:59:30 <fray> works for me!
16:59:31 <fray> thanks!
16:59:36 <bluelightning> thanks everyone
16:59:41 <Crofton|work> type #endmeeting
16:59:41 <RP> bluelightning: sounds good, thanks
16:59:42 <bluelightning> #endmeeting
-------------- next part --------------
===========
#oe Meeting
===========

Meeting started by bluelightning at 16:05:17 UTC. The full logs are
available at oe/2013/oe.2013-10-08-16.05.log.html .

Meeting summary
---------------
* LINK: https://wiki.debian.org/MeetBot   (Crofton|work, 16:06:13)
* community concerns  (bluelightning, 16:22:29)
  * LINK: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4304
    (rburton, 16:29:16)

* layers  (bluelightning, 16:40:22)

* next meeting  (bluelightning, 16:56:57)
  * ACTION: bluelightning send out meeting invite for nov 5th
    (bluelightning, 16:58:14)

Meeting ended at 16:59:42 UTC.

Action Items
------------
* bluelightning send out meeting invite for nov 5th

Action Items, by person
-----------------------
* bluelightning
  * bluelightning send out meeting invite for nov 5th
* **UNASSIGNED**
  * (none)

People Present (lines said)
---------------------------
* bluelightning (53)
* Crofton|work (46)
* RP (37)
* fray (30)
* rburton (6)
* Crofton-bot (4)
* JaMa (1)
* rp (0)
* koen (0)
* khem (0)

Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot