<span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><div>OE TSC Meeting 03-Jan-2012</div><div><br></div><div>Attendees: Paul, Mark, Tom, Richard</div>
<div>Apologies: Khem</div><div>Notes: Jefro (not present during meeting)</div><div><br></div><div>______________________________________________________________________________________</div><div>Agenda & Results</div>
<div><br></div><div>0) Welcome Paul</div><div>==> Jefro: update meeting invitation</div><div> [[NOTE: I don't have the invitation on my calendar! is it a zombie?]]</div><div><br></div><div>Agree on meeting chair</div>
<div>--> Mark</div><div>==> RP to send log to Jefro</div><div><br></div><div>psplash - update-alternatives</div><div>--> build multiple psplash executables, one for each required image</div><div>generally happy with update-alternatives to be used for this purpose</div>
<div><br></div><div>License Field</div><div>--> adopting SPDX namespace is reasonable</div><div>--> debate between doing a global (oe-core) switch to SPDX namings at this point or continuing to using mappings to export the SPDX namings..</div>
<div>--> not a compelling reason at this time to </div><div> *) Do a global change </div><div> *) Enable a QA warning </div><div> *) Plan for a QA error</div><div>--> nice to create a -disabled- QA class to check this stuff that people can enable for themselves</div>
<div><br></div><div>DISTRO_FEATURES (<a href="http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/10941" target="_blank" style="color:rgb(17,85,204)">http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/10941</a>)</div>
<div>==> continue discussion on main mailing list</div><div><br></div><div>Items deferred to next meeting:</div><div><br></div><div>Further discussion - trivial patches</div><div>Status report on oe-core</div><div>Infrastructure</div>
<div>Action Review:</div><div> Khem/Fray: Flagging on wiki for OE version</div><div> Fray: Yocto non-gplv3 testing</div><div> Khem: OE default source mirror</div><div><br></div><div>Next meeting: 17-Jan-2012</div><div>
<br></div><div>______________________________________________________________________________________</div><div>Raw Transcript</div><div><br></div><div>(17:04:08) bluelightning [~paul@pdpc/supporter/professional/bluelightning] entered the room.</div>
<div>(17:04:14) fray: as Song said on the Yocto call.. we're all still recovering from the holidays.. ;)</div><div>(17:04:23) fray: I'm trying to remember what I was doing prior to disappearing for a week</div><div>
(17:04:36) fray: a very nice and relaxing week.. (but I'm ready to "do" something again)</div><div>(17:04:40) bluelightning: hi guys</div><div>(17:04:46) fray: welcome..</div><div>(17:04:56) fray: (if there is a meeting today) this is your first meeting then?</div>
<div>(17:05:06) bluelightning: it would be yes :)</div><div>(17:06:24) fray: I think we technically have enough for a quorum.. but I'm not sure it makes sense to meet..</div><div>(17:06:57) bluelightning: I do have some issues to raise but I think it would be better if there were more people to discuss them</div>
<div>(17:07:23) Tartarus [<a href="mailto:trini@pixelshelf.com" target="_blank" style="color:rgb(17,85,204)">trini@pixelshelf.com</a>] entered the room.</div><div>(17:07:24) mode (+v Tartarus) by ChanServ</div><div>(17:07:31) Tartarus: So I guess there is one this week, heh</div>
<div>(17:07:32) fray: ok.. pinging Tom worked.. ;)</div><div>(17:07:45) fray: I just pinged Khem as well</div><div>(17:08:51) mode (+v bluelightning) by ChanServ</div><div>(17:09:04) RP__: welcome to the TSC bluelightning! :)</div>
<div>(17:09:12) bluelightning: RP__: thanks :)</div><div>(17:09:12) Tartarus: Yes, welcome bluelightning!</div><div>(17:09:39) bluelightning: is there anything I need to know right now? I guess I need to join the mailing list?</div>
<div>(17:11:05) Tartarus: yeah, join the ML</div><div>(17:11:11) fray: yup.. that is pretty much it..</div><div>(17:11:13) Tartarus: And I guess we need to get jefro to update the calendar invite</div><div>(17:11:25) fray: ahh yes..</div>
<div>(17:12:09) RP__: bluelightning: we're currently meeting at this time for an hour once every other week</div><div>(17:12:28) RP__: We're been missing Jefro recently as I'm not sure he can make this time due to a conflict :(</div>
<div>(17:12:40) fray: ya.. :(</div><div>(17:13:18) RP__: bluelightning: what's your preferred address for the tsc list?</div><div>(17:13:35) bluelightning: RP__: @linux.intel one</div><div>(17:13:45) RP__: bluelightning: ok, I'll sub you</div>
<div>(17:13:49) bluelightning: RP__: thanks</div><div>(17:14:35) RP__: bluelightning: you should be on it now</div><div>(17:14:50) RP__: So, agenda?</div><div>(17:14:59) RP__: I think everyone is recovering after the holidays :/</div>
<div>(17:15:24) Tartarus: Yeah</div><div>(17:16:09) RP__: bluelightning: FWIW, we normally come up with an agenda and then run through it</div><div>(17:16:24) RP__: bluelightning: did you have some topics you wanted to bring up?</div>
<div>(17:16:32) bluelightning: RP__: yes I had a couple</div><div>(17:17:21) bluelightning: the first was what to do about psplash, whether we should use the update-alternatives method that a couple of people seem to like</div>
<div>(17:18:42) RP__: 1) Agree on meeting chair</div><div>(17:18:42) RP__: 2) psplash - update-alternatives</div><div>(17:18:42) RP__: 3) Status report on oe-core</div><div>(17:18:42) RP__: 4) Infrastructure</div><div>(17:19:02) RP__: Beth also wanted me to bring up license fields</div>
<div>(17:19:05) fray: (action items from the last meeting)</div><div>(17:19:15) bluelightning: the second was to try to move forward on the issue of DISTRO_FEATURES expansion</div><div>(17:20:18) RP__: <a href="http://www.openembedded.org/wiki/TSC" target="_blank" style="color:rgb(17,85,204)">http://www.openembedded.org/wiki/TSC</a></div>
<div>(17:20:33) RP__: bluelightning: expansion? you mean extending the list?</div><div>(17:20:56) RP__: fray: were there any?</div><div>(17:20:58) bluelightning: RP__: yes, avoiding pain for distro maintainers</div><div>(17:21:25) RP__: <a href="http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014563.html" target="_blank" style="color:rgb(17,85,204)">http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014563.html</a></div>
<div>(17:21:30) fray: khem and I to talk to the person who suggested the flagging on the wiki</div><div>(17:21:43) fray: (quick update, I don't believe that has happened, so it's still a TODO)</div><div>(17:21:49) RP__: and we ran out of time on the trivial patch discussion</div>
<div>(17:22:01) fray: ahh yes</div><div>(17:22:03) bluelightning: RP__: <a href="http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/10941" target="_blank" style="color:rgb(17,85,204)">http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/10941</a></div>
<div>(17:22:13) bluelightning: last msg is where we're currently at</div><div>(17:22:32) bluelightning: am happy to continue the discussion to the mailing list as long as someone responds</div><div>(17:22:37) RP__: bluelightning: did you read the TSC discussion on this?</div>
<div>(17:22:53) RP__: bluelightning: I can't remember where we left off :(</div><div>(17:23:06) bluelightning: RP__: I believe I did at the time but I might need to refresh my memory</div><div>(17:23:18) fray: ohh my other action from last meeting.. Check on the status of non GPLv3 testing..</div>
<div>(17:23:23) RP__: ok, does a meeting make sense today given where we are at?</div><div>(17:23:41) fray: there is a test run -- but there is some kind of error so it's not being run regularly (or it is an is erroring)..</div>
<div>(17:23:49) fray: RP__ yes I think so</div><div>(17:25:29) ***RP__ is putting a better agenda together</div><div>(17:26:37) RP__: Agree on meeting chair</div><div>(17:26:37) RP__: psplash - update-alternatives</div><div>
(17:26:37) RP__: License Field</div><div>(17:26:37) RP__: DISTRO_FEATURES (<a href="http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/10941" target="_blank" style="color:rgb(17,85,204)">http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/10941</a>)</div>
<div>(17:26:37) RP__: Further discussion - trivial patches</div><div>(17:26:37) RP__: Status report on oe-core</div><div>(17:26:37) RP__: Infrastructure</div><div>(17:26:37) RP__: Action Review:</div><div>(17:26:37) RP__: Khem/Fray: Flagging on wiki for OE version</div>
<div>(17:26:37) RP__: Fray: Yocto non-gplv3 testing</div><div>(17:26:37) RP__: Khem: OE default source mirror</div><div>(17:27:03) RP__: anyone want to chair?</div><div>(17:27:18) fray: I can if you want</div><div>(17:27:22) RP__: bluelightning: we're normally better organised than this, sorry</div>
<div>(17:27:31) bluelightning: RP__: no worries :)</div><div>(17:27:33) RP__: fray: ok :)</div><div>(17:27:33) fray: (truely we are) ;)</div><div>(17:27:48) fray: ok.. so item 1, meeting chair done.. (just to verify, someone is capturing the log to send to Jefro?)</div>
<div>(17:27:55) ***RP__ will do so</div><div>(17:28:07) fray: ok.. item 2.. psplash -- bluelightning?</div><div>(17:28:57) bluelightning: so it would be nice if we could make it easy to customise the psplash within distro/other customisation layers</div>
<div>(17:29:36) fray: the issue as I understand it, how to provide the one file that includes the image correct?</div><div>(17:29:46) bluelightning: fray: kind of</div><div>(17:29:58) fray: the file itself is compiled in? or loaded at runtime?</div>
<div>(17:30:03) RP__: fray: I think some people want to have multiple psplash recipes for the different images</div><div>(17:30:07) bluelightning: it's compiled in, that makes it a little tricky</div><div>(17:30:09) bluelightning: when it was discussed on the mailing list koen proposed we use his scheme which uses update-alternatives to switch between psplash executables</div>
<div>(17:30:10) RP__: fray: compiled in</div><div>(17:30:12) fray: ok</div><div>(17:30:36) fray: my concern with u-a is that it still requires you to have a custom (set) of psplash executables..</div><div>(17:30:37) bluelightning: personally I think update-alternatives is a little bit of an overkill for something where only one ought to be installed into an image</div>
<div>(17:30:45) fray: it almost sounds like we need a combination of the two..</div><div>(17:31:04) RP__: allowing the default psplash header to be overridden easily would certainly be an improvement</div><div>(17:31:05) fray: one, a simple way to specify one (or more) image files.. and then a u-a to specify the "right" one to use</div>
<div>(17:31:22) bluelightning: RP__: my patch did improve that slightly</div><div>(17:31:29) fray: if given a set of splash files -- it should fairly easy to iterate over them, I'd hope</div><div>(17:31:36) fray: then use the order to specify the u-a...</div>
<div>(17:32:00) fray: (I understand why koen wants multiple splash files.. I've had similar customer requests in the past)</div><div>(17:32:04) RP__: The question is whether u-a makes sense for psplash</div><div>(17:32:23) bluelightning: fray: can you articulate the use case?</div>
<div>(17:32:30) fray: example.. one radio created for a car maker who has multiple brands.. when the radio is first initialized it detects the brand and selects the correct splash</div><div>(17:33:05) bluelightning: fray: hmm, but the same image is used for all of those brands? no other customisation?</div>
<div>(17:33:09) fray: correct</div><div>(17:33:25) bluelightning: have to say I'm surprised, but fair enough</div><div>(17:33:49) fray: some image.. everything is controled by settings within the radio that are determined based on initial "programming" of radio settings when either first powered up -- or installed in the vehicle</div>
<div>(17:34:12) fray: (this is common today with the "MyGig" radios that Chrysler uses.. not they do NOT run Linux...)</div><div>(17:34:50) bluelightning: fray: ok, so the determining setting is something that might come from a boot parameter? or some location in nvram?</div>
<div>(17:35:20) fray: ...short answer -- yes</div><div>(17:35:45) bluelightning: just trying to figure out how we can make this useful in the context of OE-core</div><div>(17:35:50) fray: the FS would contain all of the branded components, and it would be selected prior to the customer getting it -- but that doesnt change the contents of hte disk</div>
<div>(17:36:07) RP__: The question is whether u-a would provide for the variety of ways in which people might want to customise things or are we better off keeping out of this for OE-Core</div><div>(17:36:09) fray: I think best way is select a set of branded files -- and then use the u-a..</div>
<div>(17:36:14) fray: anything beyond that gets to be very custom</div><div>(17:37:21) bluelightning: so psplash needs to be modified to read a separate file for the image?</div><div>(17:37:48) RP__: There is next to no code in pslash</div>
<div>(17:37:55) fray: What I'm thinking is that we build multiple psplash exectuables -- for each image</div><div>(17:37:59) fray: ('er.. graphic)</div><div>(17:38:18) fray: then dynamically package them into seperate packages using u-a to set the order..</div>
<div>(17:38:36) RP__: Tartarus: any thoughts?</div><div>(17:38:45) Tartarus: nope</div><div>(17:38:46) fray: then the user could simply set something that says "SPLASHFILE = file://foo1 file://foo2 ... file://fooN"</div>
<div>(17:38:58) bluelightning: hmm ok, that shouldn't be too tricky</div><div>(17:39:14) fray: then leave the default alone w/ oe branding and it's easy to rebrand</div><div>(17:39:51) bluelightning: ok, so we're generally happy with u-a being used for this?</div>
<div>(17:40:16) RP__: bluelightning: reluctantly</div><div>(17:40:17) fray: I think this is one of the cases where it makes sense</div><div>(17:40:25) bluelightning: ok</div><div>(17:40:26) fray: (it's overkill for most users though)</div>
<div>(17:40:31) RP__: you can make a case for u-a anywhere</div><div>(17:41:14) bluelightning: ok thanks guys</div><div>(17:41:33) RP__: so license fields - Did anyone read Beth's proposals?</div><div>(17:41:57) RP__: The question is what to do about the LICENSE field - do we encourage any standardisation</div>
<div>(17:42:00) fray: yes -- I think it's good... I expect corner cases.. but the obvious ones have likely been flushed out</div><div>(17:42:23) fray: I think we need to encourage it. If SPDX is the standard naming we choose.. then we use that + an alternative namespace for thins that don't "fit"</div>
<div>(17:42:34) RP__: I'd suggest the answer is yes, we'd like to see standardisation but I'd propose we adopt SPDX with the addition that we map "v" to "-"</div><div>(17:42:56) RP__: So we don't have to change all our GPLv2 to GPL-2</div>
<div>(17:43:06) Tartarus: Well</div><div>(17:43:19) Tartarus: Might that not be a pain to want now, for other benefits?</div><div>(17:43:20) fray: I was expecting we'd have a pass over everything.. and then warn for things that don't match a known name..</div>
<div>(17:43:29) Tartarus: Or no, SPDX using tools won't be groking these files?</div><div>(17:43:30) fray: Tartarus thats my current thinking..</div><div>(17:43:47) fray: Tartarus SPDX tooling won't directly grok recipes.. those are ours..</div>
<div>(17:44:04) fray: SPDX tooling will need an XML SPDX file to grok.. one that we can point to via the recipe..</div><div>(17:44:17) RP__: Any time we pass something to SPDX tools the v to - mapping is straightforward</div>
<div>(17:44:30) fray: (and at some point, I'd expect we're going to want to mandate the inclusion of such files.. but until the tooling exists.. there is nothing to mandate)</div><div>(17:44:52) Tartarus: OK, so, continuing down the devils advocate path</div>
<div>(17:45:05) Tartarus: is there a reason other than not wanting to change a bunch of files?</div><div>(17:45:09) fray: teh place where mapping would be needed is validation tools.. things that read in the SPDX data (once it exists) and compares our source/binary package declarations vs what the SPDX file says</div>
<div>(17:45:23) Tartarus: bikeshedding and all that, SPDX chose - for a reason</div><div>(17:45:42) Tartarus: Maybe we should just say we're adopting their standard (with "+ for stuff that doesn't fit")</div>
<div>(17:45:52) Tartarus: rather than adopting except we like vN not -N</div><div>(17:46:21) fray: The discussion Paul and I and Beth have had on the mailing list is:</div><div>(17:46:34) fray: SPDX naming w/ && and || designations..</div>
<div>(17:46:34) RP__: Tartarus: I just hate the idea of forcing users to update metadata everywhere for a "v" to "-" change</div><div>(17:46:54) RP__: Tartarus: I don't mind other bits and cleaning up licenses in general but that change seems more annoying than useful</div>
<div>(17:46:57) fray: along with an alternative namespace for things that don't fit.. such as "other:Adobe:Reader"</div><div>(17:47:05) fray: prefix:company:license"</div><div>(17:47:34) RP__: Tartarus: its easier for people to spend time changing metadata if there is a clear benefit to it</div>
<div>(17:48:15) fray: ya.. we still havn't hit the clear benefit area.. but I expect there to be one</div><div>(17:48:20) Tartarus: Right, so I'm saying the clear benefit is "follow the standard"</div><div>
(17:48:41) Tartarus: Yeah, we could just fix it up in our export tool</div><div>(17:48:43) fray: by itself.. the change will do nothing since we don't (yet) having tooling beyond white/black list -- correct?</div><div>
(17:48:56) RP__: Tartarus: Is there any reason the - won't work or would cause confusion?</div><div>(17:49:07) RP__: fray: correct</div><div>(17:49:43) Tartarus: RP__: The - or the v ? My assumption is that the SPDX folks already spent hour arguing v vs - and came to a conclusion that - is best</div>
<div>(17:49:48) fray: I'm worried about the confusion bit mysel..</div><div>(17:49:52) Tartarus: I personally like LICvN</div><div>(17:50:24) bluelightning: I have to say I do too, but for none other than aesthetic reasons</div>
<div>(17:50:24) RP__: Tartarus: personally I do to...</div><div>(17:50:55) fray: (I'm quickly skimming to see if there is anything noted beyond aestetics)</div><div>(17:51:01) RP__: I've been around a few flag day type changes before for OE and I just find them painful every time</div>
<div>(17:51:27) RP__: I appreciate this isn't quite a flag day but the only want to do it is for people to start seeing tons of hard errors :(</div><div>(17:51:29) fray: they call what we're discussing the "SPDX License List short form identifier"</div>
<div>(17:51:30) Tartarus: If the answer is that no, we don't see using SPDX names as-is is enough of a benefit to do the search and replace then OK, we'll just not do it until there is a clear benefit, other than just using the standard</div>
<div>(17:52:07) fray: can I propose that we suggest future packages following this SPDX License List short form identifies names.. :)</div><div>(17:52:18) RP__: I think mapping against their license types and building up a standard for the LICENSE field is a good thing and there is a benefit there</div>
<div>(17:52:25) fray: and at some point we validate and warn.. then we can error if/when the tooling makes it reasonable?</div><div>(17:52:34) RP__: but mapping 1:1 with their names, I'm seeing no strong reason for</div>
<div>(17:52:51) RP__: fray: don't warn unless we're going to force a switch</div><div>(17:53:03) RP__: we have way more important warning messages to fix and this would drown them out</div><div>(17:53:07) fray: RP__ yes.. I meant that as a precursor to a switch, some time in the future..</div>
<div>(17:53:17) fray: I wouldn't mind a (disabled) QA test now though</div><div>(17:53:18) ***RP__ wishes people would pay attention to warning messages</div><div>(17:53:19) Tartarus: I'd suggest that at some point we'll have people writing recipes that have SPDX info and we'll see 'incorrect' LICENSE fields? :)</div>
<div>(17:53:58) RP__: I'd like to see a list of known types we accept in the field</div><div>(17:54:00) bluelightning: I think we already have SPDX naming mixed in don't we?</div><div>(17:54:07) RP__: bluelightning: we do</div>
<div>(17:54:14) fray: FYI.. it simply states the identifier and version number should be separated by a "-"</div><div>(17:54:28) fray: so they are using that to indicate a parsing point but that is all I see</div>
<div>(17:54:40) fray: FYI it's Appendix I on the spdx-1.0 specification</div><div>(17:54:57) fray: so they have GPL-2.0 and GPL-2.0+ later meaning that version or greater</div><div>(17:54:59) RP__: fray: right, its likely so you can automatically split the version from the main license</div>
<div>(17:55:14) bluelightning: aha, that would make sense</div><div>(17:55:15) fray: they also have things like GPL-3.0-with-GCC-exception</div><div>(17:55:27) RP__: and we support GPLv2 GPLv2.0 (with + variants)</div><div>
(17:55:41) RP__: fray: I think we've started adopting those</div><div>(17:55:59) fray: ya.. if we did this (even w/ v = -) then GPLv2 is invalid..</div><div>(17:56:19) RP__: fray: We currently have a mapping table</div>
<div>(17:56:29) fray: ya.. I would expect we'll need to continue to have that</div><div>(17:56:38) fray: perhaps the mappign table is the right way to do the v -> -?</div><div>(17:56:45) fray: then ask people to switch to -?</div>
<div>(17:56:52) RP__: fray: <a href="http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/license.bbclass" target="_blank" style="color:rgb(17,85,204)">http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/license.bbclass</a></div>
<div>(17:57:13) fray: ahh yes I see..</div><div>(17:57:40) fray: ok.. so do we have a conclusion on this topic?</div><div>(17:58:13) fray: I'll summarize what I see then...</div><div>(17:58:29) fray: We still think SPDX naming and what Beth is proposing is reasonable..</div>
<div>(17:58:58) fray: There is debate between doing a global (oe-core) switch to SPDX namings at this point or continuing to using mappings to export the SPDX namings..</div><div>(17:59:23) fray: other then risk of confusion, there is not a compelling reason at this time to *) Do a global change *) Enable a QA warning *) Plan for a QA error</div>
<div>(17:59:42) fray: (it might be nice to create a -disabled- QA class to check this stuff that people can enable for themselves)</div><div>(17:59:50) fray: do you agree? did I miss anything?</div><div>(18:00:28) Tartarus: Sounds right</div>
<div>(18:00:45) fray: Ok.. so Beth is on the right track, we're non-commital beyond that for now.. and we should keep monitoring..</div><div>(18:00:59) fray: ok.. it's 12 (central).. Do we want to continue or do we need to call it?</div>
<div>(18:01:14) ***RP__ has to be somewhere else now :(</div><div>(18:01:24) fray: ok.. then we'll call it and defer the other items..</div><div>(18:01:36) bluelightning: sounds OK to me</div><div>(18:01:37) fray: if any of the items are pressing we should call a meeting for next week -- otherwise next meeting in 2</div>
<div>(18:01:52) RP__: I don't think we did much with the action items :(</div><div>(18:02:09) RP__: status of OE-Core hasn't changed much over the holidays</div><div>(18:02:22) fray: agreed</div><div>(18:02:24) RP__: DISTRO_FEATURES is the main pressing item</div>
<div>(18:02:37) RP__: I'd suggest we try and continue that on the maining list</div><div>(18:02:48) RP__: maybe we can all try and have more discussion on that topic there?</div><div>(18:02:51) fray: ok.. sounds good to me..</div>
<div>(18:02:56) bluelightning: agreed, hopefully with people coming back from holiday they will be able to respond</div><div>(18:03:18) RP__: sounds like a plan</div><div>(18:03:28) RP__: so meeting in a fortnight?</div><div>
(18:03:37) fray: yup -- unless we decide otherwise</div><div>(18:03:40) bluelightning: yep</div><div>(18:03:41) fray: (via mailing list)</div><div>(18:03:44) RP__: right</div><div>(18:03:58) ***RP__ sends the log to jefro</div>
<div class="yj6qo ajU" style="outline-style:none;outline-width:initial;outline-color:initial;padding-top:10px;padding-right:0px;padding-bottom:10px;padding-left:0px;width:22px;margin-top:2px;margin-right:0px;margin-bottom:0px;margin-left:0px">
</div></span><div><br></div>-- <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>