[oe] OE TSC Minutes 7 May 2013

Jeff Osier-Mixon jefro at jefro.net
Tue May 21 19:36:54 UTC 2013


OpenEmbedded Technical Steering Committee
7 May 2013

Attendees:
  Koen (koen)
  Khem (khem)
  Fray (fray)
  Paul (bluelightning)
  Richard (RP)
Apologies:

Notes: Jefro

Agenda at a glance:

1. pick a chair
2. new issues
3. lingering issues
a. systemd merge unhappiness
4. projects in progress - status
a. oe-classic recipe migration status
b. oe-core release
c. systemd into master
d. meta-oe appends/overlayed recipes RFC
e. 1.5 planning
5. infrastructure
a. mailing list moving to YP server, in progress
b. oe.org flooded
6. projects deferred
a. raise awareness of "janitor" list, QA "bugs"
b. document whitespace changes to the shell
c. raise ntp with the Yocto Project [RP]

________________________________________________________________
Agenda & Results

1. pick a chair
koen
___________________________________
2. new issues

a. phil's questions about the role of the TSC
(http://lists.linuxtogo.org/pipermail/openembedded-core/2013-April/038756.html)
original charter is to look at issues, and attempt to resolve them
the pull model removed a lot of the reason the TSC was created
two functions of the TSC: working group/task force type activities and
actual decision making
 also administrative functions
TSC could chair it but make it a public IRC thing
-> proposal: monthly IRC meeting to replace one of the bi-weekly TSC
meetings, open to all
 timezone will be an issue
=> think about for next meeting

___________________________________
3. lingering issues

a. systemd merge unhappiness ~> release status notification
=> maintain a wiki page to summarize release goals (jefro)
=> status emails (RP) - ongoing

___________________________________
4. projects in progress - status

a. oe-classic recipe migration status
some recipes migrated but then kept in own layers
also cherry picking parts of layers like meta-oe
need some documentation on right way to synchronize

b. oe-core release
1.4.1 is being worked on along with 1.3.2

c. dropped

d. meta-oe appends/overlayed recipes RFC
no avr32 support in public layers
paul has patches to remove bbappends, pending discussion on ml
everything uncontested has been sent for review
qt4/qt tools stuff troublesome
-> still remaining: busybox and gst-ffmpeg bbappends, xserver-nodm-init
=> RFC switching wholeheartedly to libav (bluelightning)

e. 1.5 planning
RP on sabbatical

f. python 3
hard to support both py2 and 3
two issues: python3 on target, using p3 for bitbake
don't think we can reasonably support both
make the switch in the 1.5 timeframe?
need to start informing people of it -now-..
___________________________________
5. infrastructure

a. mailing list moving to YP server
in progress

b. oe.org flooded
    refs to oe.org git should point to github
=> fix the oe wiki and reminder to ml (khem) <= remove
=> investigate YP hosting, kernel.org mirror (jefro)

___________________________________
6. projects deferred

a. raise awareness of "janitor" list, QA "bugs"
defer to after 1.4

b. document whitespace changes to the shell
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
http://www.openembedded.org/wiki/Styleguide
https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide
=> still need to de-dup these, need a volunteer
ask for volunteers after 1.4 (jefro)

c. raise ntp with the Yocto Project [RP]
immediate need addressed, reasonable default needed
use LICENSE_FLAGS - non-commercial
no default set after Paul's changes
RP raised with YP AB
=> going to mailing lists & someone should write a proposal
=> fray will send to list after 1.4

________________________________________________________________
Raw Transcript

(8:59:19 AM) Jefro: good heavens, everyone is here
(8:59:29 AM) koen: yes
(8:59:33 AM) koen: 17:55 < koen> this must be a record, every tsc
member present 5 minutes early :)
(8:59:47 AM) ***RP is here :)
(9:00:22 AM) Jefro: there isn't some disaster I haven't heard of yet, is there?
(9:01:05 AM) Jefro: I even have an agenda: http://pastebin.com/0nSZm90B
(9:01:48 AM) koen: shall I chair?
(9:02:15 AM) RP: koen: fine with me
(9:02:24 AM) RP: Are fray, khem, bluelightning alive?
(9:02:35 AM) bluelightning: hi all, yes I'm here
(9:02:58 AM) RP: I'd like to add python3 to the agenda somewhere
(9:03:11 AM) koen: 4f ?
(9:03:55 AM) koen: no objections, so 4f  python3
(9:04:03 AM) Jefro: (added to my copy)
(9:04:10 AM) koen: let's wait a bit for khem and fray to wake up
(9:04:38 AM) fray: sorry.. I'm here
(9:05:46 AM) ***fray is busy playing with the new office build server.. :)
(9:05:48 AM) fray: was distracted
(9:06:22 AM) koen: looks like we have quorum, let's hope khem shows up soon
(9:06:45 AM) koen: 1 - pick a chair <- done
(9:06:47 AM) fray: sounds good
(9:06:48 AM) koen: 2 - New issues
(9:07:09 AM) ***RP isn't aware of any
(9:07:17 AM) koen: me neither
(9:07:22 AM) bluelightning: nor me
(9:07:26 AM) RP: Actually, I guess there is Phil's email
(9:07:37 AM) koen: which one specifically?
(9:07:38 AM) RP: His questions about the role of the TSC
(9:07:40 AM) bluelightning: oh good point
(9:07:44 AM) koen: ah that one
(9:08:03 AM) fray: Wow, I missed that one which list?
(9:08:14 AM) RP: I want to be clear for the record that this is
something that ultimately the members need to decide on
(9:08:19 AM) ***Jefro doesn't see that on the mailing list
(9:08:26 AM) koen: the mail: http://pastebin.com/wK9eNccG
(9:08:31 AM) RP: however I believe the TSC can offer an opinion
(9:08:47 AM) koen: crap, that stripped the quote levels
(9:08:48 AM) bluelightning: RP: sounds reasonable
(9:09:14 AM) koen:
http://lists.linuxtogo.org/pipermail/openembedded-core/2013-April/038756.html
(9:10:33 AM) fray: I wish I had seen that earlier.. must have slipped by..
(9:10:39 AM) bluelightning: as far as being superfluous to
requirements I guess we could only point to the issues the TSC has
resolved (both with the code and infrastructure) in the recent past
(9:11:09 AM) RP: bluelightning: As I said in my reply, the TSC has
been behaving more as a task force though :/
(9:11:29 AM) RP: the trouble is we have no power to ask anyone other
than ourselves to do anything :/
(9:11:33 AM) fray: Briefly, IMHO the TSC role is to look at issues,
and attempt to resolve them..  If members bring up technical issues..
to issue guidance... but we can't 'force' anyone to do anything
specific IMHO
(9:12:01 AM) koen: what about this hypothetical:
(9:12:14 AM) koen: Yocto Project wants to do $foo for 1.6
(9:12:19 AM) koen: TSC is against $foo
(9:12:41 AM) fray: then the TSC needs to work it out......
(9:13:17 AM) fray: If it causes a rift, then that is what happens..
but the TSC should idenfity the issue.. bring it up to our YP board
member and have it brough through that way..  Worst case, the YP does
their own thing..
(9:13:28 AM) Jefro: I would guess you could also s/Yocto Project/OE
community/ there
(9:13:36 AM) khem: hi guys
(9:13:54 AM) koen: hey khem
(9:13:57 AM) fray: I really do thing of the TSC as a community
advocate.. but we don't get a lot of community input, other then the
mailing list..
(9:14:06 AM) bluelightning: that was the original goal, to resolve
technical disputes
(9:14:11 AM) fray: (and when we do, I see us bringing it up)
(9:15:00 AM) RP: koen: There is an implied understanding that the
OE-Core maintainership respects the TSC, even if other layers don't
(9:15:05 AM) fray: bluelightning ya.. and there haven't been a lot of those..
(9:15:15 AM) fray: (which IMHO is a good sign)
(9:15:32 AM) khem: well, tsc IMO can also help with some interaction
with other projects
(9:15:46 AM) koen: RP: you imply that "OE-Core maintainership" is a YP
thing, not an OE or OE/TSC thing
(9:16:02 AM) fray: RP, ya.. it's really up to the maintainers to
decide on governance flows..  but any 'official' OE layer that doesn't
follow TSC guidance seems like a problem to me.. either
misunderstanding or worse..
(9:16:22 AM) RP: koen: I don't imply either case actually
(9:16:29 AM) ***koen rereads
(9:16:33 AM) fray: the community working on the layer is the one that
sets the maintainer role.. if the community doesn't like the
direction, at least for oe layers, the TSC should be able to work with
the maintainer or worse case replace them..
(9:16:43 AM) koen: RP: you're right, sorry about that
(9:16:46 AM) fray: (and I do mean worse case.. I really never want to
push out someone willing to provide their time as maintainers0
(9:17:36 AM) RP: OE-Core was established by the TSC (as was meta-oe
and other layers as part of the restructuring OE underwent)
(9:18:20 AM) koen: so the TSC still serves a purpose
(9:18:38 AM) fray: frankly if everything ran smoothly all the time and
there was never a question, concern, etc for the TSC.. then dissolving
the TSC would be reasonable... but so far we've had agenda items that
IMHO are more then just talking points..
(9:18:44 AM) koen: but the pull model makes issues less frequent
(9:18:48 AM) RP: I put a lot of my thoughts into my reply to that email
(9:18:48 AM) fray: koen, yes I do think it does..
(9:19:00 AM) RP: but yes, the pull model removed a lot of the reason
the TSC was created
(9:19:26 AM) bluelightning: koen: the more clear delineation of distro
policy helps as well
(9:20:06 AM) RP: I do wonder if we should split out the functions the
TSC now fulfils explicitly
(9:20:22 AM) RP: As I see it there are two - the working group/task
force type activities and actual decision making
(9:20:43 AM) RP: I'd like to see the former perhaps opened up to more people
(9:20:53 AM) Jefro: I would suggest that the TSC also now serves an
administrative function. It monitors infrastructure issues, finds
resources for documentation issues, tracks major changes, and also
provides semi-weekly information updates to the mailing lists (when I
remember to send minutes out on time).
(9:21:08 AM) RP: The TSC could chair it but make it a public IRC thing
(9:21:22 AM) fray: I wouldn't object to that
(9:21:28 AM) Jefro: RP: that's a really good idea
(9:21:46 AM) bluelightning: sounds like a good idea, might help avoid
these tasks always falling on our heads :)
(9:22:26 AM) RP: I am just thinking out loud here but I think the idea
that the TSC adapt to the changes in the overall OE ecosystem is a
good one
(9:22:47 AM) RP: and I think there are some adoptions that can take place
(9:23:18 AM) Jefro: how about a monthly IRC-based open forum,
replacing one of these bi-weekly TSC meetings? time of day will be an
issue - OE is a worldwide community
(9:23:18 AM) RP: but the idea would be for more involvement of other people
(9:23:49 AM) RP: Jefro: That is roughly my thinking. We'd just have to
pick a time that works for the TSC members. If there is demand we can
consider expanding it to other timezones
(9:23:52 AM) khem: yeah IRC meeting is fine
(9:24:02 AM) khem: I think most folks are in US and EU
(9:24:09 AM) khem: so something around this time may work
(9:24:24 AM) khem: may be use the same time slot
(9:24:33 AM) koen: nearly half past, still on 2) new issues
(9:24:35 AM) khem: since we all have this time slot available
(9:24:38 AM) fray: ya.. this seems to be the best time for a lot fo stuff..
(9:25:03 AM) RP: So how about we go away and think about this. Also
see what feedback there is from members about this?
(9:25:19 AM) bluelightning: yep soliciting feedback from members would be good
(9:25:25 AM) RP: We should try and have some kind of proposal for the
next meeting? It would be best discussed on the members list though?
(9:25:29 AM) khem: yeah I think notifying ahead of time will be good
(9:25:37 AM) khem: so members can plan to attend it
(9:26:03 AM) RP: We're not agreeing to do this yet, just discuss it more widely
(9:26:30 AM) fray: ya.. this is a place to definitely ask the e.V. members
(9:26:54 AM) koen: yes, e.V. members list would be a good place
(9:26:55 AM) RP: The TSC would remain an elected decision making body
but wouldn't have scheduled meetings like we have now (instead maybe
once a quarter or something) unless a decision was needed
(9:28:01 AM) koen: not so sure about that, it's harder to see if
people are still involved or AWOL with bi-weekly meetings
(9:28:28 AM) RP: koen: we'd have the replacement irc working group meetings
(9:28:31 AM) fray: koen with-out-?
(9:28:40 AM) RP: koen: so attendance would be pretty clear still
(9:28:42 AM) koen: yes, without
(9:29:20 AM) koen:  The TSC would remain an elected decision making
body but wouldn't have scheduled meetings like we have now (instead
maybe once a quarter or something) unless a decision was needed, but
irc working group meetings will be frequent
(9:29:25 AM) koen: something like that?
(9:29:27 AM) fray: that all seems reasonable to me.. doesn't really
change what we've been doing...  just makes it clearer to the
community
(9:29:38 AM) RP: koen: yes
(9:29:49 AM) RP: irc working group meetings would replace the current
scheduled TSC meetings
(9:30:11 AM) khem: seems good
(9:30:20 AM) RP: It separates the decision making role of the TSC from
other work
(9:31:13 AM) fray: ok.. so what about the comment of an 'oe'
maintainer ignoring the TSC?
(9:31:18 AM) koen: do we need more discussion or can we move down the agenda?
(9:31:27 AM) fray: koen, I'm happy to move it down
(9:31:29 AM) RP: I'd move on with the agenda
(9:31:57 AM) koen: 3. lingering issues
(9:32:03 AM) koen: a. systemd merge unhappiness
(9:32:11 AM) RP: For 3a, I'd agreed to provide status updates. I've
now provided two of these
(9:32:24 AM) Jefro: wiki page is not yet done
(9:32:27 AM) RP: I'm trying to turn it into a habit
(9:32:50 AM) RP: Did people like/dislike them?
(9:32:52 AM) koen: and there's a discussion going on on how to do
libexec properly, which was one of the items
(9:33:13 AM) ***fray reads them and likes them..
(9:33:21 AM) RP: Right, libexec is a hard problem but the right
discussion is happening
(9:33:22 AM) fray: I've even forwarded some of the info on into my
organization..
(9:33:34 AM) RP: I need to reply to that email (was away for a few days)
(9:33:40 AM) khem: yes update email is very nice
(9:33:48 AM) bluelightning: I'm still unclear on how people using
meta-systemd view the current oe-core systemd situation - have we
resolved all issues or are there still things that need looking into?
(9:34:12 AM) bluelightning: I guess that's a question for the ml
(9:34:17 AM) koen: right
(9:34:23 AM) RP: bluelightning: yes
(9:34:36 AM) koen: so
(9:34:46 AM) koen: onto 4 then
(9:34:54 AM) koen: 4 a. oe-classic recipe migration status
(9:35:23 AM) koen: there was a discussion on keeping .incs or not, not
much else afaics
(9:35:31 AM) koen: (correct me if I missed something)
(9:35:32 AM) bluelightning: yeah, ongoing... not a huge amount of
migrations since last meeting
(9:36:03 AM) bluelightning: it's worth noting I'm aware that some
people have migrated recipes and then kept them in their own layers
(9:36:35 AM) bluelightning: which is not hugely bad but it would be
nice if they could send them somewhere more appropriate
(9:36:59 AM) RP: bluelightning: any idea why they're doing that?
Simply don't know any different?
(9:37:10 AM) koen: I bet it's easier
(9:37:15 AM) koen: no hassle with "upstreaming"
(9:37:24 AM) fray: one thing that has hit me lately (related) is when
a recipe needs something in meta-oe.. but I don't want meta-oe.. so
now I have a potential conflict..  that might be something we have to
address in the future..
(9:37:30 AM) bluelightning: RP: not sure, possibly they solved their
own issue and hadn't got around to submitting
(9:37:56 AM) RP: fray: This is something we designed combo-layer to be
able to handle - pulling out specific parts of a layer with history
(9:38:00 AM) fray: (i.e. meta-selinux provides swig.. meta-selinux is
designed to run w/ just oe-core...)  now I want to add meta-networking
components.. which require other meta-oe components (incuding swig)..
(9:38:01 AM) bluelightning: fray: but why don't you want meta-oe?
(9:38:06 AM) khem: fray: I dont want meta-oe but I need one recipe
from it approach has to change - we need to make meta-oe better
(9:38:07 AM) RP: fray: I do this locally...
(9:38:08 AM) fray: oo big
(9:38:09 AM) fray: too big
(9:38:11 AM) khem: so people can use it
(9:38:23 AM) khem: may be YP compatible one day
(9:38:28 AM) fray: RP, exactly.. I'm doing it locally.. but I havn't
seen much documentation around the 'right' way to syncronize this
stuff.. that's all
(9:38:59 AM) RP: fray: I did want to document both combo-layer and my
workflow for 1.4 but ran out of time :(
(9:39:02 AM) ***fray didn't intend to start a topic here.. just good
for thought moving forward...)  it's a real problem we need to figure
out
(9:39:04 AM) koen: so before going on a tangent
(9:39:06 AM) fray: RP, no worries..
(9:39:12 AM) koen: any other OE classic issues?
(9:39:25 AM) bluelightning: koen: no I think we're done on that specific issue
(9:39:25 AM) khem: I see more drastic changes in BSP layers e.g. to
some recipes like udev rules
(9:39:50 AM) khem: meta-oe is way more pleasant
(9:40:10 AM) RP: For 4b, I don't have much to say. 1.4.1 is being
worked on along with 1.3.2
(9:40:27 AM) bluelightning: right
(9:40:34 AM) RP: I think 4c can be dropped
(9:40:38 AM) fray: yup
(9:40:54 AM) koen: d. meta-oe appends/overlayed recipes RFC
(9:41:12 AM) bluelightning: so we're almost there on 4d
(9:42:03 AM) koen: Ross has been shuffling around the gnome stuff
(9:42:29 AM) bluelightning: still remaining: busybox and gst-ffmpeg
bbappends, and the xserver-nodm-init situation
(9:42:57 AM) bluelightning: I have failed to get anyone interested in
the busybox bbappend
(9:43:31 AM) koen: the gst-ffmpeg one is tricky
(9:43:42 AM) bluelightning: indeed
(9:43:42 AM) khem: bluelightning, I will try to get busybox issue fixed
(9:44:11 AM) koen: we'd need to ask martin about the xserver-nodm-init thing
(9:44:21 AM) bluelightning: koen: what concerns me is both ffmpeg and
libav seem to be proceeding independently
(9:44:34 AM) koen: ffmpeg shouldn't be used anymore
(9:44:58 AM) koen: libav is much more open to being used as a shared lib
(9:45:29 AM) bluelightning: perhaps we should just RFC switching
wholeheartedly to libav and see if anyone objects
(9:45:36 AM) koen: sounds good
(9:45:52 AM) bluelightning: ok I'll take that AR then
(9:46:04 AM) koen: thanks
(9:46:13 AM) koen: let's move to 4e. 1.5 planning
(9:46:16 AM) bluelightning: khem: thanks
(9:46:39 AM) fray: FYI https://wiki.yoctoproject.org/wiki/Planning
(9:46:41 AM) koen: most important point for 1.5: RP will go on sabbatical
(9:46:46 AM) fray: YP planning information has now been posted..
(9:47:00 AM) fray: this should start to give people an idea of what
work the YP is planning on
(9:47:06 AM) bluelightning: can someone expand on "RP supports
PACKAGECONFIG proposal" ?
(9:47:21 AM) RP: bluelightning: I think this was to PACKAGECONFIG more recipes
(9:47:28 AM) bluelightning: ah ok
(9:47:36 AM) RP: bluelightning: remove the need to bbappend, have
people set mode config options
(9:47:51 AM) bluelightning: and PACKAGECONFIG to enable deps on things
outside OE-Core as well presumably
(9:48:01 AM) bluelightning: (as discussed on the ml a few weeks ago)
(9:48:06 AM) fray: yup
(9:48:08 AM) RP: So yes, I have some extended leave coming up
(9:48:24 AM) RP: I'm planning to make some of the branch merging about
the only "work" thing I do
(9:48:48 AM) RP: bluelightning: that is fine as long as the defaults
reflect that
(9:49:04 AM) bluelightning: RP: right
(9:50:26 AM) RP: questions/concerns about me being away?
(9:50:59 AM) khem: RP have fun :)
(9:51:08 AM) koen: any more on 1.5 planning?
(9:51:30 AM) koen: 4f. python 3
(9:51:50 AM) koen: so I guess this is about bitbake/python3
(9:51:51 AM) khem: I have python3
(9:51:54 AM) RP: I've done some research on this. There are some nasty
changes which make it hard to support both py2 and 3
(9:52:14 AM) koen: I'd like to have a python_3.x.bb as well
(9:52:24 AM) koen: what's the problem with making it py3 only?
(9:52:25 AM) RP: There are two separate issues here
(9:52:26 AM) khem: actually python3 on target is one and then using p3
forr bitbake is another
(9:52:27 AM) koen: RHEL?
(9:52:44 AM) RP: One is the question of bitbake itself, the other is
the question of a recipe
(9:52:48 AM) fray: RHEL/CentOS is a big problem
(9:52:52 AM) RP: I'm ignoring the latter right now
(9:53:02 AM) khem: koen: I do have patches for adding p3 support on target
(9:53:08 AM) RP: The question is should the project take the plunge and go py3
(9:53:12 AM) RP: and if so, which py3 ?
(9:53:14 AM) khem: I plan to post them soon in couple of weeks
(9:53:45 AM) khem: RP: you mean python for bitbake
(9:53:50 AM) RP: We do have our standalone python tarball to support
python 2.x distros
(9:53:51 AM) RP: khem: yes
(9:53:56 AM) fray: I don't have any objection to going to p3 (whatever
version is reasonable) -- if we have a way to supply -- or help
someone get p3 on their host..
(9:54:21 AM) RP: I'm making the assumption we can get py3 recipes and
those would build for nativessdk
(9:54:37 AM) koen: khem says he has started that
(9:54:49 AM) khem: our experiences has been good with python 3.3.x
(9:54:54 AM) RP: Right, to be the harder part is bitbake itself
(9:54:58 AM) RP: s/be/me/
(9:55:15 AM) RP: Would we want to make the switch in the 1.5 timeframe?
(9:55:27 AM) khem: my recipes are for target and mostly and some -native support
(9:55:36 AM) khem: havent tried nativesdk yet
(9:55:40 AM) RP: We're increasingly trying to use modern language
features and finding old 2.x bugs :(
(9:55:46 AM) RP: I suspect Martin is seeing those for example
(9:56:02 AM) fray: I think it's reasonable to mvoe to p3 in the 1.5 time frame..
(9:56:19 AM) fray: but we need to start informing people of it -now-..
(9:56:29 AM) RP: My feeling is that we should seriously consider
updating if we can get all the pieces together
(9:56:31 AM) fray: roughly 6 months is enough time for someone to
seriously object -- or help
(9:56:32 AM) khem: RP: do we want to then not support 2.x for bitbake
or we want to keep it both
(9:56:40 AM) bluelightning: RP: do you have an idea of how much impact
it'll have on the metadata?
(9:56:45 AM) RP: khem: I don't think we can reasonably support both
(9:56:53 AM) fray: my preference is to support both -- but that sounds
unreasonable at this point
(9:56:56 AM) khem: yeah its hard
(9:57:03 AM) RP: bluelightning: there are annoyances and there will be problems
(9:57:11 AM) RP: bluelightning: not massively amounts of them
(9:57:38 AM) khem: as an experiences internal teams tried to support
both for their projects and gave up on p2
(9:58:03 AM) RP: Ok, we're running out of time
(9:58:11 AM) bluelightning: if we have to actually completely switch
to python3 and stop supporting python2-only, I've got to say I'm not
particularly keen on that..
(9:58:19 AM) RP: I'm going to propose we announce an intent to switch in 1.5
(9:58:41 AM) RP: This will only happen if each of the key requisites
comes together
(9:59:01 AM) RP: (builds work, builds aren't any slower, we have a
story for people without py3)
(9:59:24 AM) fray: yup..
(9:59:27 AM) fray: I'm happy with that
(9:59:32 AM) koen: me too
(9:59:50 AM) khem: me too
(10:00:05 AM) bluelightning: right, ok
(10:00:11 AM) RP: so we warn people now, we still need to decide on
exact specifics like which py3 we'll support
(10:00:35 AM) fray: warning should go to both bitbake-devel and all oe lists..
(10:00:41 AM) khem: yes
(10:00:42 AM) koen: I bet it will be like the py2.x version
requirements we had in the past
(10:02:11 AM) koen: anything more on 4f?
(10:02:44 AM) koen: 5a. mailing list moving to YP server, in progress
(10:02:44 AM) khem: nope
(10:03:03 AM) Jefro: 5a is in process, Michael is working with Florian
(10:03:16 AM) khem: archives are created, Michael is waitng on florian
to copy them over to yp server location
(10:03:22 AM) khem: he created for florian
(10:04:37 AM) Jefro: I think folks are drifting to their 10am meetings
(10:04:46 AM) khem: yes heh
(10:04:53 AM) khem: I have at 10:30
(10:05:01 AM) koen: 5b b. oe.org flooded
(10:05:03 AM) Jefro: for 10b I have not yet explored the possibility
of moving oe servers to yp
(10:05:22 AM) Jefro: I have also not seen a lot of complaints on the
list, so perhaps this is a lower priority item
(10:05:35 AM) fray: I think it's something we need to watch and prepare for..
(10:05:43 AM) fray: but I agree, I've seen a significant lack of complaints..
(10:06:13 AM) khem: fix the oe wiki and reminder to ml (khem) can be
removed I guess ?
(10:07:21 AM) RP: I'm afraid I need to go. I'm not sure I have much to
add to the rest of the agenda, will read scroll back later
(10:07:48 AM) Jefro: I think it's done - the rest is deferred items
(10:07:52 AM) koen: right
(10:07:52 AM) fray: np.. we can move to next time..
(10:07:55 AM) fray: thanks!
(10:07:56 AM) koen: I think we can close
(10:08:03 AM) bluelightning: thanks all
(10:08:49 AM) khem: bye

--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org



More information about the Openembedded-devel mailing list