OE-TSC minutes, 19-May-2011 Attendees: Richard, Koen, Mark, Khem, Stefan Apologies: Tom, Jefro
Agenda with notes: 00) difference between an interest group with OE-Core as a focus and the TSC koen promotes that hands-on steering group is better than advisory interest group fray & RP think that made sense for oe-core, but now want to move bulk of work to ml RP worries that hands-on oe-core was not original charter of TSC 01) Agree on meeting chair RP 02) Status report on oe-core announced on mailing list micro and slugos work towards oe-core 20-30% of the OE recipes with all the layers stefan thinks one last .dev release fray wouldn't suggest closing dev until oe-core release generally accepted koen would like GNOME in before closing .dev long term maint on 2011.03 --> GNOME discussion to ml (all) --> release issues to ml, interest in 2011.06 (stefan) 03) Status report on pull model, contrib repo and guidelines 04) Status report on board support layer guidelines fray: version I send out tomorrow or early next week is likely the final then wiki 05) Status on layer splitting of metadata consolidate oe-core and oe-devel mailing lists? separate patches list bitbake list on oe.org RP proposes bitbake-devel (checked with Chris and he is ok with this) possibly also meta-<machine> or meta-general for hardware discussions meta-slug has slugos stuff, meta-ti has animal boards, meta-smartphones... --> look at migrating bitbake mailing list (RP) 06) Continue discussions on infrastructure items Raw transcript: (20:54:36) ***RP__ is here (20:56:30) ***koen too (20:56:37) ***stefan_schmidt as well (20:56:54) ***fray is here (20:58:34) khem: I am back (21:01:08) RP__: ok, Tom and Jefro send their appologies (21:01:26) RP__: we need a chair since I think we're all here (21:01:30) stefan_schmidt: means everyone else is here (21:01:41) ***RP__ can do it if nobody else wants to (21:02:50) RP__: ok. Did Jeff send out an agenda? (21:02:58) RP__: I think the mail I saw was confused? (21:02:58) stefan_schmidt: yes (21:03:05) stefan_schmidt: right (21:03:11) stefan_schmidt: now an updated one :) (21:03:15) fray: ahh was the the agenda? ;) (21:03:32) RP__: stefan_schmidt: when did that come out/ (21:03:32) RP__: ? (21:04:11) stefan_schmidt: hmm, let me check (21:04:15) RP__: Is this the mail with subject "DRAFT Minutes for 12 May 2011"? (21:04:18) koen: I saw something on IRC that I needed to comment on something, but I coldn't deduce what from the backlog (21:04:24) stefan_schmidt: To me it looked like an old agenda. But maybe I confused it. khem koen (21:04:32) stefan_schmidt: Not my day today anyway... (21:05:05) RP__: koen: We talked about the difference between an interest group with OE-Core as a focus and the TSC (21:05:20) RP__: koen: I asked people to think about it and come back to this meeting having thought about it (21:05:24) koen: ah, right (21:05:31) RP__: koen: Yours was homework :) (21:05:45) RP__: So who has done this? :) (21:05:59) fray: I thought about it.. but I'm not sure I have much to add.. (21:06:00) koen: the backlog said something like "were now talking about #4, 5 and 6" (21:06:14) koen: and I needed to comment on one, but I couldn't figure out which one (21:06:22) fray: I think interest groups are the right answer for keeping the TSC as a decision making body.. vs what we are mostly doing now -- implementing the direction (21:06:38) stefan_schmidt: hmm, my mail seems to be broken. Can't find the agenda mail right now (21:06:40) koen: we are a *steering* group (21:06:57) koen: I have no problems with a hands-on tsc (21:07:07) fray: ya.. I think what we did for oe-core made sense.. but now that it's "open", it needs to be an interest group.. the hands-on is what got it moving.. (21:07:14) koen: but an IG would take a lot of work out of the tsc's hands (21:07:20) RP__: koen: but I think the time is for the mailing lists to take a greater role and this team a little bit of a lesser one (21:07:50) koen: RP__: you might have noticed me saying "let's move that to the ml" the past few meetings :) (21:07:57) RP__: koen: My worry was when you look at the agenda we focused on oe-core to pretty much the exclusion of anything else (21:07:58) fray: :) (21:08:07) RP__: and I worry that isn't what the TSC should be doing (21:08:29) koen: not much to to in .dev worlds (21:08:42) koen: frans stopped deleting stuff (21:08:57) koen: people post scary things for review first (21:09:05) RP__: koen: I agree, I'm just thinking we need to probably mentally shift gear at this point a little and I'm highlighting that (21:09:43) RP__: So, agenda wise do we feel we need to cycle through the usual items? (21:09:49) koen: we could do some handwaving like the previous TSC (21:09:54) koen: rename some git branches and stuff (21:10:42) stefan_schmidt: RP__: I would say we could either cycle or diretcly bring up topics (21:10:54) RP__: 01) Agree on meeting chair (21:10:54) RP__: 02) Status report on oe-core (21:10:54) RP__: 03) Status report on pull model, contrib repo and guidelines (21:10:54) RP__: 04) Status report on board support layer guidelines (21:10:54) RP__: 05) Status on layer splitting of metadata (21:10:54) RP__: 06) Continue discussions on infrastructure items (21:10:58) stefan_schmidt: normally we find our way to the topics without the agenda... (21:11:03) koen: RP__: TBH, I consider .dev a dead end (21:11:11) RP__: 01) - Me, nexy (21:11:21) RP__: koen: I agree, I think the future is clear (21:11:37) RP__: but we have the transition ahead (21:11:38) koen: what remains is figuring out when it will go read only (21:11:40) stefan_schmidt: 02) micor and slug os work towards oe-core (21:11:48) ***RP__ feels the mailing list has generally been positive (21:11:55) stefan_schmidt: shows up some things that wasn't found before. good. (21:12:15) stefan_schmidt: koen: first we need a last release from .dev (21:12:16) RP__: koen: I think its still premature to discuss that atm (21:12:34) RP__: So we're clearly on 02) btw :) (21:12:45) RP__: We announced OE-Core (21:12:58) fray: (btw questions about R/O switches, etc.. this is what the TSC should be doing.. vs an IG) (21:13:00) RP__: I wish I had more time to write more instructions but I don't and I really could use some help there (21:13:32) koen: RP__: we're still at 20-30% of the OE recipes with all the layers (21:13:43) RP__: Phil has caught some path issues which we've promptly fixed (21:13:52) koen: personally, I'd like to get GNOME in before even thinking about closing .dev (21:14:03) RP__: koen: It'll take a while but we will get there (21:14:17) RP__: Should we have the gnome discussion now? (21:14:36) koen: that can go onto the ml :) (21:14:43) RP__: ok (21:15:01) khem: stefan_schmidt: we already have made last release from .dev (21:15:08) stefan_schmidt: anything else in oe-core land this week? (21:15:13) khem: next release is supposed to be on oe-core (21:15:16) RP__: I think we're at least 3 months of thinking about dev closure (21:15:20) stefan_schmidt: khem: err, no? (21:15:36) stefan_schmidt: khem: we did plan to have 2011.06 from it and then going ro (21:15:41) fray: I wouldn't suggest closing dev until we've got an oe-core release and it's generally accepted.. (21:15:42) khem: stefan_schmidt: we have a long term maintainence on 2011.03 (21:15:43) RP__: ok, anything else on oe-core (21:15:44) koen: with the maintenance branch doign well, we might not need a new release (21:15:46) stefan_schmidt: At least that is what I remember (21:15:47) khem: it wont make much sense (21:15:54) RP__: I'd like to thank khem for the slugos work btw :) (21:16:22) khem: RP__: yes I wanted to experience what would it take to add a new distro (21:16:28) fray: One question on oe-core.. (21:16:29) khem: and surprisingly it was not much (21:16:45) stefan_schmidt: koen, khem: That depens if people are interested in doing another release (21:16:54) fray: I noticed the email today about the overall changelog.. I'm getting overwealmed with email recently.. Is there a plan to do something similar w/ oe-core? (21:16:57) RP__: khem: cool, that is good to know (21:17:17) RP__: khem: I hoped and thought as much but its nice to hear it confirmed :) (21:17:18) koen: fray: oe-core is at the bottom of that mail :) (21:17:20) khem: stefan_schmidt: I would refrain from another release on .dev since we have a branch already on 2011.03 there wont be much users in 11.06 (21:17:26) fray: An announce type list with changelogs would definitately help people keep up.. but it should definitely be automated.. (21:17:33) fray: koen, ahh heh I didn't make ti that far.. (21:17:40) RP__: fray: Wasn't that on the bottom? :) (21:18:08) fray: I only looked at the angstrom stuff.. (21:18:09) koen: fray: alphabetically sorted, cbrake will change it next time (21:18:19) RP__: I'd should mention I've concentrated on some detailed patch review over the past 24 hours so pull merging is sluggish atm (21:18:26) RP__: normal server will resume shortly :) (21:18:33) khem: fray: oe-commits (21:18:48) stefan_schmidt: khem: I not against dropping the release. We just had another plan before :) (21:18:59) khem: RP__: on patch review I think we should decide if we want to use patchwork or not (21:19:07) fray: koen, my suggestion isn't to resort it.. just have something at the top listing all of the places that will be listed.. (21:19:08) RP__: Regarding releases I'd only do them if they make sense and there is a need (21:19:27) RP__: khem: I've been meaning to contrast it with gerrit (21:19:46) RP__: khem: patchwork doesn't seem to personally buy me much atm (21:19:51) khem: releases take considerable time and I think there wont be many users for 11.06 on .dev given there is 11.03 long term (21:19:52) stefan_schmidt: RP__: Fine with me. We would need to find people running the release anyway (21:20:04) stefan_schmidt: I think khem is not interested and Tom busy with 2011.03 (21:20:23) stefan_schmidt: So maybe nobody will care nayway. But we should at least discuss it before dropping (21:20:43) RP__: stefan_schmidt: agreed but those sound like reasonable reasons to me (21:21:05) stefan_schmidt: sure, we can fir up a mail for in in some weeks and look at the feedback (21:21:12) RP__: stefan_schmidt: I'd take silence as acceptance ;-) (21:21:18) khem: RP__: I would rather spend time releasing based on oe-core (21:21:19) stefan_schmidt: Buglabs won't go for 2011.06 anyway (21:21:25) RP__: khem: agreed (21:21:38) RP__: ok, anything else on oe-core? (21:21:48) RP__: pull model, contrib repo and guidelines? (21:21:58) fray: based on the fact it's already almost 2011.06 -- and I haven't seen anyone pushing for a release (and lots of patches going into 2011.03) I don't know that it's needed either (21:22:13) RP__: board support layer guidelines? (21:22:19) fray: guidelines.. based on the feedback I've gotten so far.. the version I send out tomorrow or early next week is likely the final... (21:22:52) RP__: fray: sounds good. Where is the end result going? (21:22:54) RP__: wikis? (21:22:56) stefan_schmidt: Well, to close the release discussion here. AR: for me sending a mail about interest in an 2011.06 release and asking for volunteers if needed (21:22:57) khem: We also need to consolidate oe-core and oe-devel mailing lists (21:23:02) khem: as we move forward (21:23:16) fray: RP__ mailing list for final comments.. back to us for a "vote".. and then yes.. wiki (21:23:20) RP__: khem: I actually want to maintain some list separation for the patches (21:23:37) fray: I just want the final to be clearly the opinion of the TSC before we publish to the wiki (21:23:43) RP__: stefan_schmidt: I'd send an email out but mention low interest and nobody taking it on? (21:23:46) khem: RP__: yes we should have oe-patches and oe-devel separate (21:23:47) RP__: fray: agreed (21:24:03) RP__: khem: no, I think we need to separate oe-core as it is now (21:24:12) RP__: one place where all oe-core changes/patches go (21:24:15) RP__: clear separation (21:24:16) fray: for now, I think oe-core is needed still.. (21:24:26) stefan_schmidt: RP__: I was thinking about these lines. I don't want to push it. Just want to let people know that we may drop it due to lack of interest (21:24:29) RP__: which brings up a topic I wanted to raise - the bitbake mailing list (21:24:37) fray: if and when dev is locked down and email dies down.. then we can consolodate (21:24:53) khem: fray: yes (21:25:02) RP__: should we move the bitbake list from berlios where nobody can find it onto linux2go? or onto yocto? (21:25:09) RP__: at the moment people don't use it as the email lags badly on it (21:25:21) fray: RP__ --yes-- (21:25:24) khem: RP__: yes oe.org would be ok (21:25:30) stefan_schmidt: RP__: is it the last item on berlios? (21:25:32) fray: I'd love it to be on oe.org (21:25:39) RP__: stefan_schmidt: bitbake releases are there too (21:25:50) stefan_schmidt: RP__: hmm, ok (21:25:51) ***RP__ thinks we should move the mailing list urgently though (21:26:16) RP__: so who can admin mailing lists and setup a bitbake one on oe.org? (21:26:39) stefan_schmidt: I don't have much of an opinion here, but if people that use it more have problems these should be fixed (21:26:40) koen: 'bitbake' is ok for the name? (21:26:46) khem: mailman on ltg needs updated too or fixed. It given wrong thread views (21:26:52) RP__: koen: I don'ts ee why not (21:26:54) fray: koen, ya, I would like "bitbake" as the name (21:27:00) RP__: or bitbake-devel? (21:27:07) RP__: its currently bitbake-dev I think (21:27:19) khem: well given our convention -devel is logical (21:27:43) fray: no objection.. (21:27:52) RP__: Anyhow, I think moving it would help people find it and enable more bitbake discussion in the right place (21:28:06) RP__: no objections? (21:28:12) khem: RP__: will it also involve moving archives (21:28:25) koen: I'm looking at the form now (21:28:33) RP__: khem: yes, and inviting subscribers to the new list and making the old one read-only (21:28:41) khem: RP__: ok (21:28:45) khem: I support that (21:29:17) stefan_schmidt: no objection from me (21:29:38) koen: bitbake or bitbake-devel? (21:30:22) khem: one think that I was seeing is that lot of people have different boards and they are currently supported in oe now they need machine layers on top of oe-core (21:30:45) khem: they are not supported by vendors per say (21:31:00) khem: where to host them we need something like meta-machiens (21:31:00) ***RP__ proposes bitbake-devel (21:31:24) khem: yes bitbake-devel is fine on ml (21:31:24) RP__: khem: Could that not be a directory in meta-oe? (21:31:50) khem: RP__: yes it could be (21:32:11) khem: so should we create another layer under meta-openembedded (21:32:29) khem: meta-machines ? (21:32:32) khem: or some such (21:32:38) fray: I think it depends on if we're trying to build up meta-oe -- or if we're trying to provide examples for new people doing work (21:32:43) RP__: I think that makes sense atm (21:32:56) fray: if examples and new work is the goal, then new layers (even if they're under meta-oe) is the right approach... (21:33:04) RP__: I think meta-oe needs to grow some of this stuff initially then things can split out as needed (21:33:10) fray: if we're just trying to move things forward from dev, then meta-oe is the "obvious" answer to me (21:33:14) khem: agreed (21:33:21) fray: RP__ ya, thats kind of what I'm thinking as well.. (21:33:28) fray: we need machine layer examples.. but it may still be premature (21:34:12) khem: RP__: should it be general layer meta-misc-machines (21:34:22) khem: or like meta-<machine> (21:34:30) khem: I guess general (21:34:38) RP__: probably general (21:34:42) khem: ok (21:34:45) RP__: we can go too far with splitting things up (21:34:51) koen: I really don't want machines in the meta-oe repo (21:34:56) khem: thats what I was guessing (21:34:57) fray: ya.. I'm a bit worried about the "over splitting" (21:35:04) khem: right now I have almost 10 layers (21:35:11) khem: for building 2 distros and 4 machines (21:35:12) fray: koen, I think we need to have some... all of them, likely not.. (21:35:14) khem: :) (21:35:47) RP__: koen: I think it is ok as long as they are split out and enabled separately (21:35:49) fray: khem, my experience with layers (before oe) is that around 10 is manageable.. more starts to get confusing (21:37:55) koen: let me put it another way (21:38:01) RP__: ok, is there anything else we need to talk about? (21:38:10) koen: if it lives in the meta-oe repo, I'm not going to maintain that machine layer (21:38:45) RP__: koen: I think that is ok, we just need to define areas of ownership (21:39:22) fray: koen, I think that needs to be part of the readme in the meta-oe.. there is layer and component maintainers.. (21:39:34) fray: IMHO it's perfectly acceptable to define multiple owners/maintainers (21:40:12) khem: koen: we need those machines somewhere to get users using new setup for their familiar machine (21:40:52) koen: paulE is picking up the handhelds stuff (21:41:06) koen: meta-smartphones has the phones (21:41:18) koen: meta-slug has the slug (21:41:22) khem: koen: will they under meta-openembedded ? (21:41:26) koen: meta-ti has the animals (21:41:49) fray: is the real issue that people don't know where to look for the machines? (21:42:11) koen: I think so (21:43:09) koen: there aren't a whole lot of useful machines left in .dev that aren't in a layer already (21:43:20) koen: (or have a layer planned, e.g. gumstix) (21:43:31) fray: and I definitely want to avoid moving machines nobody is going to use.. its the few remainers that concerns me (21:44:27) fray: As a TSC, would it be reasonable to state.. the preferred way of doing this is a "machine" layer.. one that contaisn on or more related amchines.. (21:44:45) fray: in the event a machine layer will not be created, it can go into meta-oe, but requires a named maintainer for the minimal functionality? (21:45:05) koen: right (21:45:24) RP__: all pieces of meta-oe need clearly named maintainers or groups of maintainers and a defined way they make decisions (21:45:40) khem: correct (21:45:50) khem: no unmaintained machine is coming over thats clear (21:46:00) fray: I'm willing to ratify that.. :) (21:46:10) ***RP__ checked with Chris and he's fine with the bitbake list move btw (21:46:30) koen: sweet (21:46:43) khem: koen: how will angstrom propose the machines it supports (21:47:06) khem: koen: angstrom-scripts is geared to ti machines mainly ATM (21:47:13) koen: right (21:47:19) koen: no more machine layers around (21:47:29) koen: till I found meta-smartphone today (21:47:49) khem: ok so you will take them as they come and support angstrom ? (21:47:53) khem: right (21:48:08) koen: depends on people willing to support them for angstrom (21:48:20) khem: ok (21:49:12) ***stefan_schmidt feels we have covered all topics (21:49:20) koen: it will be influenced by http://narcissus.angstrom-distribution.org/stats.php :) (21:49:20) khem: ok (21:49:22) ***RP__ thinks so (21:49:24) stefan_schmidt: Anything important left? I'm tired today... (21:49:26) fray: yup (21:49:31) RP__: Shall we close up? (21:49:35) khem: yes (21:49:36) fray: o with me (21:49:40) RP__: Any ARs we need to capture? (21:49:49) ***RP__ will look at migrating the bitbake mailing list (21:49:51) khem: RP__: you should push the TMPDIR append patch (21:49:58) RP__: thanks to koen putting the basics in place (21:50:02) khem: it worked well here (21:50:03) stefan_schmidt: RP__: only the one for me sending a mail wrt release (21:50:36) RP__: Ok, thats it folks, meeting closed :) (21:50:46) RP__: thanks all :) (21:50:50) khem: bye (21:51:03) RP__: khem: and yes, I need to take that patch and some others (21:51:10) stefan_schmidt: night all (21:51:14) RP__: see above, I'm lagging atm, will catch up tomorrow -- Jeff Osier-Mixon http://jefro.net/blog Yocto Project Community Manager @Intel http://yoctoproject.org -- Jeff Osier-Mixon http://jefro.net/blog Yocto Project Community Manager @Intel http://yoctoproject.org
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
