OpenEmbedded TSC 8 April 2013

OpenEmbedded TSC 8 April 2013

[Jeff Osier-Mixon]

OpenEmbedded Technical Steering Committee
8 April 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
4. projects in progress - status
5. projects deferred

________________________________________________________________
Agenda & Results

1. pick a chair
RP
___________________________________
2. new issues

a. discussion on the next release
eg gcc 4.8 etc after 1.4 (khem has patchset)
bluez5, gst 1.x

___________________________________
3. lingering issues

a. SMART has replaced zypper (was documenting RPM and package feeds)
Paul wrote https://wiki.yoctoproject.org/wiki/Smart_Repository_Setup
=> khem has gotten it to work, will update the docs
=> Paul to talk to scottrif about adding to docs
NOW IN THE MANUAL, OK TO DROP

b. oe-classic recipe migration status
RP played with perl modules, fixed up cpan_build.bbclass
=> still needs to send some patches
> still need to sort out, been distracted with release

c. systemd merge unhappiness
"people feel ignored and then being told they should have spoken up"
some concern about favoritism for patches
=> maintain a wiki page to summarize release goals (jefro)
> things pretty clear on mailing list
> no status emails yet but plan to (RP)
> need to ensure sysvinit/systemd fully doc'd, ross/scott taking care of that

d. oe.org flooded
refs to oe.org git should point to github
=> jefro to follow up with scottrif DONE
=> khem to fix the oe wiki and reminder to ml
possible to move server at some point?
=> jefro to investigate YP hosting, kernel.org mirror
> some complaints about lagging behind, but is up to date within 15 minutes
> could have been a hiccup during infrastructure issues last week

___________________________________
4. projects in progress - status

a. oe-core release
autobuilder issues
qemuimagetest will change significantly in 1.5
ptest a good addition
much more to integrate in 1.5

b. infrastructure
see 4d

c. systemd into master - still in progress

d. mailing list outage
mailing list moving to OSUOSL or YP
list addresses will not change
work in progress

e. meta-oe appends/overlayed recipes RFC
http://lists.linuxtogo.org/pipermail/openembedded-devel/2013-February/043925.html
no avr32 support in public layers
=> paul has patches to remove bbappends, pending discussion on ml
http://lists.linuxtogo.org/pipermail/openembedded-devel/2013-February/043964.html
everything uncontested has been sent for review
qt4/qt tools stuff troublesome

f. 1.5 planning
RP supports PACKAGECONFIG proposal

___________________________________
5. 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

(9:00:32 AM) mode (+v Jefro) by ChanServ
(9:00:47 AM) Jefro: Khem is stuck in traffic, will be 15-20 mins late
(9:00:59 AM) Jefro: I'm finishing up the agenda, 1-2 mins
(9:01:17 AM) ***RP_ is here
(9:01:26 AM) ***bluelightning is here
(9:01:34 AM) fray: here
(9:06:12 AM) Jefro: good morning - so just missing koen and khem
(9:06:24 AM) Jefro: khem will be here in 10-15 mins
(9:06:24 AM) koen: 17:46 < koen> I have a conflict at 6, I'll be
attending the meeting sporadically, my apologies
(9:06:27 AM) RP_: Jefro: "(16:47:01) koen: I have a conflict at 6,
I'll be attending the meeting sporadically, my apologies"
(9:06:36 AM) Jefro: ah, got it thanks
(9:06:38 AM) ***koen just walked into the office again
(9:06:42 AM) Jefro: agenda here:  http://pastebin.com/mBhCDqR2
(9:06:57 AM) RP_: I actually cancelled other stuff so I could attend
this meeting
(9:07:48 AM) fray: UK is on day light savings now?
(9:08:01 AM) RP_: fray: yes
(9:08:01 AM) bluelightning: yes
(9:08:24 AM) fray: I assume central europe is as well then.. so we're
all back to the same relative time zones at least
(9:08:37 AM) RP_: fray: yes, it helps
(9:08:59 AM) RP_: So, should I chair for a change?
(9:09:08 AM) RP_: I think its probably my turn
(9:09:11 AM) ***fray is fine with that
(9:09:16 AM) bluelightning: me too
(9:09:35 AM) RP_: I assume we get started and khem can catch up when he joins
(9:09:42 AM) RP_: Any additions to the agenda
(9:09:44 AM) RP_: ?
(9:09:55 AM) fray: One thing, discussion on "the next release"..
(9:10:16 AM) fray: if any.. I'm more thinking about plans like gcc 4.8
and stuff like that after the upcoming release..
(9:10:38 AM) bluelightning: fray: I guess you saw khem already has a
patchset for that
(9:10:39 AM) koen: fray: like bluez5 and gst 1.x?
(9:10:40 AM) fray: (and BTW I'm happy if we say there isn't anything
to talk about yet)  :)
(9:10:44 AM) RP_: ok
(9:10:52 AM) fray: bluelightning yup.. :)
(9:11:01 AM) fray: koen, ya exactly..
(9:11:07 AM) RP_: So, updates on section 3
(9:11:12 AM) RP_: Anything on 3a?
(9:11:28 AM) bluelightning: yep, it's now in the manual
(9:11:37 AM) fray: cool, we can drop the item?
(9:11:41 AM) RP_: bluelightning: great! :)
(9:11:49 AM) bluelightning: some extensions needed so we fully cover
what to do with ipk but the material info is there
(9:11:51 AM) RP_: bluelightning: can we consider that closed now?
(9:11:56 AM) bluelightning: yep I think so
(9:12:05 AM) RP_: great! :)
(9:12:08 AM) RP_: I still need to sort out 3b, been distracted with the release
(9:12:27 AM) RP_: which brings us to systemd
(9:12:38 AM) RP_: I think things there are pretty clear on the mailing list
(9:12:52 AM) RP_: I've not managed the status emails we've talked
about yet but still plan to
(9:13:17 AM) RP_: Anything anyone wants to add?
(9:13:26 AM) Jefro: my action item is not yet done
(9:14:19 AM) bluelightning: RP_: we need to ensure the
sysvinit/systemd stuff is fully documented and I think Ross and Scott
are taking care of that
(9:14:23 AM) RP_: We did see some favouritism comments in irc however
when looked into, most of the patches which were supposedly being
ignored had in fact been merged
(9:15:01 AM) RP_: We don't send out the "merged" replies now which
perhaps doesn't help perception
(9:15:42 AM) RP_: For 3d, any update?
(9:15:59 AM) Jefro: I did follow up with scottrif
(9:16:10 AM) RP_: bluelightning: yes, agreed. I know I've sent some
fixes to Scott about the systemd docs too
(9:16:31 AM) RP_: (I passed on some reports on irc to be clear)
(9:16:56 AM) bluelightning: someone claimed that github was lagging
behind at one point
(9:17:05 AM) bluelightning: I did not follow up on the claim but it
concerned me at the time...
(9:17:23 AM) RP_: bluelightning: :/
(9:18:15 AM) RP_: bluelightning: I guess we should check it has caught up...
(9:18:57 AM) bluelightning: OE-Core is up-to-date at this moment at least
(9:19:13 AM) RP_: bluelightning: ok, that is good at least...
(9:19:14 AM) fray: I saw that (github) a few weeks ago.. and it caught
up pretty quickly.. and it was up to date within 15 minutes..
(9:19:20 AM) bluelightning: could have been a hiccup during the
infrastructure issues we had about a week ago
(9:19:24 AM) RP_: Moving to 4a, OE-Core release status
(9:19:24 AM) fray: since then, I havn't noticed the lag.. so I think
it was a hickup
(9:19:54 AM) RP_: We've had serious issues with the new autobuilder
infrastructure highlighting existing race issues and qemu bugs
(9:20:12 AM) RP_: I'm hoping today that we nailed down the last one of
those but its been causing me some serious stress :/
(9:20:42 AM) bluelightning: we're probably one of the few using that
code I suspect
(9:20:54 AM) bluelightning: FWIW, it's not documented other than
what's in local.conf.sample
(9:21:04 AM) bluelightning: (qemuimagetest I mean)
(9:21:13 AM) RP_: There are a number of other issues out there, some
kernel issues with routerstationpro, udev and multilib issues, there
have also been a number of fixes going into master for things like
CVEs
(9:21:29 AM) RP_: and the postinst issues of where there have been several
(9:21:57 AM) RP_: bluelightning: qemuimagetest isn't going to be worth
documenting in its current form now as it will change in 1.5 quite
massively
(9:22:07 AM) bluelightning: RP_: ok
(9:22:09 AM) RP_: bluelightning: and yes, we're clearly the main
people using it.
(9:22:12 AM) khem
[~khem@99-57-140-209.lightspeed.sntcca.sbcglobal.net] entered the
room.
(9:22:13 AM) mode (+v khem) by ChanServ
(9:22:18 AM) fray: hey
(9:22:19 AM) khem: hrmpp
(9:22:22 AM) khem: I am here
(9:22:28 AM) RP_: That code does help us a lot with our testing and is
extremely important
(9:22:30 AM) bluelightning: khem: we are on 4a OE-Core release status
(9:22:31 AM) RP_: hi khem
(9:22:38 AM) RP_: khem: agenda: http://pastebin.com/mBhCDqR2
(9:22:44 AM) RP_: khem: We're talking about 4a
(9:22:51 AM) fray: ya.. it helps keep the quality level up.. and is
something we need to keep using, even if the project itself is the
only user
(9:23:01 AM) fray: (even though it apparently isn't foolproof)  :(
(9:23:09 AM) RP_: fray: Plans in 1.5 are to integrate a lot more into it
(9:23:22 AM) bluelightning: it's crucial, and we need to be doing even
more runtime testing
(9:23:23 AM) RP_: fray: automate a lot more of the manual QA into
there and add -ptest support etc
(9:23:37 AM) khem: ok
(9:23:38 AM) RP_: but for 1.4, I'm hoping we have this stablised for now
(9:23:51 AM) fray: my concern when it comes to qemu and integration is
handling architectures that QEMU doesn't support (or processor
optimizations).. but as long as the fall back continues..  I do like
that qemu helps us with testing, etc..
(9:23:51 AM) RP_: We're also having to backport the fixes for it to 1.3.x
(9:23:57 AM) fray: the ptest stuff is really a nice addition as well
(9:24:14 AM) RP_: fray: the fallback is how we'd handle that, yes
(9:24:23 AM) khem: w.r.t. ptest is there some document on it
(9:24:28 AM) fray: RP_, ya so from a technical direction, I think
we're doing the right things..
(9:24:38 AM) khem: like what differnet packages are currently ptestifies
(9:24:42 AM) bluelightning: khem: no, but I have pinged Bjorn about that today
(9:24:47 AM) khem: and what can one do to add more
(9:24:51 AM) fray: (might even spur some BSP writings to improve QEMU
for their specific processors)
(9:24:57 AM) bluelightning: khem: I suggested he talk to Scott about
getting that in
(9:24:57 AM) RP_: so, 1.4 is in its final stages, I was extremely
nervous about it, I'm less nervous today but still not entirely
comfortable
(9:25:37 AM) RP_: khem: at this point I think those things will have
to be a specific objective of 1.5
(9:25:39 AM) fray: RP_, if it makes you feel any better.. the work
I've been doing on master has shown that it's way better then 1.2 and
1.3 were (in hindsight)..
(9:26:04 AM) RP_: fray: that is good, I'd hate the opposite to be true! :)
(9:26:20 AM) RP_: Any concerns/questions with 1.4?
(9:26:34 AM) khem: RP_: yes thats more of doc/wiki issue so not as
much important for release
(9:26:59 AM) RP_: khem: there is a chance we may still be able to sort
that for the release, we'll see
(9:27:13 AM) RP_: khem: I want to turn the eglibc/gcc tests into ptest btw :)
(9:27:41 AM) khem: RP_: yes thats what I was leaning towards
(9:27:43 AM) RP_: khem:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4216 may make
interesting reading for you btw - that sanity issue I mentioned
(9:28:24 AM) RP_: khem: any update on 4b? (mailing list migration) ?
(9:28:43 AM) RP_: 4c I think progress is clear on the mailing list, it
will be in 1.4
(9:29:01 AM) khem: RP_: thats cool fix
(9:29:02 AM) RP_: Jefro: 4b and 4d are the same?
(9:29:04 AM) bluelightning: we desperately need to move forward on
that, mailing lists broke again last week (at least the web archive
did)
(9:29:22 AM) Jefro: 4b is a  placeholder, 4d has matured into its own project
(9:29:23 AM) fray: bluelightning did it ever get fixed (web archives)?
(9:29:27 AM) khem: RP_: I have been looking at qemu commits on master
for some hints but could not spend lot of time
(9:29:33 AM) bluelightning: fray: yes they are working now
(9:29:36 AM) fray: good
(9:29:37 AM) Jefro: I have a small update on 4d - Tom is working with
Florian and choosing between moving to OSUOSL or YP
(9:29:57 AM) Jefro: so it is in progress
(9:29:57 AM) bluelightning: Jefro: great!
(9:30:04 AM) RP_: Jefro: If we were to go the YP route, Michael would
be able to help FWIW
(9:30:05 AM) fray: excellent
(9:30:42 AM) RP_: Michael is invaluable, keeps all the infrastructure going
(9:30:55 AM) Jefro: I agree, although I think Tom is choosing OSUOSL -
I haven't talked to him in detail about why that is, but he knows YP
is an option
(9:31:20 AM) RP_: We've been an AB down due to memory issues recently
and the recent power upgrade was a small outage but in general we do
really well with uptime
(9:31:41 AM) khem: Jefro: Tom King ?
(9:31:54 AM) RP_: Jefro: I just hope we're not swapping one set of
problems for another, it worries me when things take a while :/
(9:32:00 AM) khem: Jefro: I will talk to him, I think yp will support
it lot better than osuosl
(9:32:20 AM) khem: not thst osuosl is bad
(9:32:38 AM) khem: I have experience handling uclibc stuff
(9:32:43 AM) khem: with osuosl
(9:33:24 AM) RP_: khem: I guess some of us appear biased so please do
talk to him :)
(9:34:04 AM) RP_: The YP is big enough now that the LF wouldn't let it
just disappear overnight
(9:34:07 AM) khem: RP_: I wil
(9:34:23 AM) khem: even if it did we can find alternatives
(9:34:37 AM) khem: and we can defer it to when it happens
(9:34:45 AM) RP_: khem: right, exactly
(9:35:04 AM) RP_: bluelightning: any update on 4e?
(9:35:13 AM) khem: I think we can benefit from Michael's promptness
(9:35:44 AM) bluelightning: RP_: I sent out the patchset, I have to
send a v2 preserving the bbappends with only PRINC settings left in
(9:35:59 AM) bluelightning: which I am not particularly happy about,
but I can accept it for the moment
(9:36:13 AM) RP_: bluelightning: sounds like progress is being made
(9:36:18 AM) bluelightning: yes
(9:36:28 AM) bluelightning: we still have a bbappend for busybox that
I don't fully understand
(9:36:36 AM) RP_: bluelightning: I'd hope they can removed entirely
with some PR bumps eventually
(9:36:48 AM) fray: bluelightning is it configuration specific or something else?
(9:37:07 AM) bluelightning: RP_: that was NACKed because "we can't
guarantee which version of OE-Core is being used with meta-oe master"
(9:37:33 AM) bluelightning: when PV is bumped we can definitely drop them though
(9:37:34 AM) RP_: bluelightning: :(
(9:37:51 AM) RP_: bluelightning: right, so we have a plan to kill them off :)
(9:37:51 AM) fray: Hmm..  meta-oe moving forward will eventually need
the master or "last release"?
(9:37:55 AM) bluelightning: RP_: right
(9:38:18 AM) khem: bluelightning: that syslog thing for busybox is for
systemd to let it use
(9:38:21 AM) RP_: I'll insert 4f, 1.5 planning
(9:38:24 AM) RP_: fray: ?
(9:38:27 AM) bluelightning: it's also worth noting there was a
follow-up discussion about how to handle optional dependencies from
stuff in OE-Core on other things that aren't
(9:38:38 AM) bluelightning: khem: so we probably need it in OE-Core right?
(9:38:42 AM) khem: otherwise it segfaults
(9:38:47 AM) bluelightning: ???!!!
(9:38:49 AM) khem: I guess so
(9:38:49 AM) fray: Sure.. briefly.. there are a few key things I'd
like to mention on the 1.5 planning.. subsystems, and other things
that we should "plan" to update
(9:38:50 AM) bluelightning: segfaults?
(9:38:54 AM) RP_: bluelightning: Although I didn't reply, I support
the PACKAGECONFIG proposal
(9:38:57 AM) fray: i.e. gcc 4.8, gstreamer, bluez..
(9:39:19 AM) fray: I assume the general rule of follow the open source
world forward still applies, so I don't know if there is as much
planning needed on any of those as was on systemd..
(9:39:29 AM) bluelightning: khem: if it's really a segfaulting problem
we really do need that in for 1.4
(9:39:31 AM) khem: I think OE-Core should use defaults that are with
in its own layer
(9:39:36 AM) khem: and provide knobs
(9:39:39 AM) fray: but is it reasoanble to move plan to move to 4.8,
1.0, 5 respectively?  (anything else)?
(9:39:42 AM) khem: so others can turn on or off
(9:39:45 AM) bluelightning: khem: that's the suggested course
(9:39:46 AM) RP_: fray: the issue with bluez and gst are the parallel
installation
(9:39:54 AM) RP_: fray: I think we have good plans on the mailing list though
(9:40:03 AM) koen: bluez, not gst
(9:40:07 AM) koen: gst is parallel installable
(9:40:09 AM) koen: bluez isn't
(9:40:18 AM) fray: that's what I was thinking.. bluez is going to be an issue..
(9:40:24 AM) RP_: koen: right, but there are plans for both on the
mailing list though
(9:40:28 AM) fray: unless we have all of the users updated -- or some
kind of a compatibility shim
(9:41:03 AM) fray: does anyone know (at this point) any other major
version changes that could affect people?
(9:41:32 AM) RP_: khem: what is glicb doing in the 1.5 timescale?
(9:41:59 AM) khem: RP_: I dont think we will make all eglibc patches
into glibc by them
(9:42:00 AM) khem: then
(9:42:11 AM) RP_: we have the 4.8 gcc branch so that is progressing well too
(9:42:19 AM) khem: RP_: I will talk to carlos when I am at Collab
(9:42:27 AM) RP_: khem: the 2.17 issue caused some segfaults in crypt :/
(9:42:32 AM) fray: (gcc 4.8 doesn't worry me.. we'll get the issues
resolved by then)
(9:42:47 AM) RP_: khem: an update on the plans there would be good
(9:42:52 AM) ***fray notes he was really surprised to hear crypt
behavior changed
(9:43:12 AM) RP_: fray: I don't know of any other major version changes
(9:43:21 AM) fray: are there any other architectures coming in for
1.5?  (aarch64?)
(9:43:40 AM) RP_: there is talk about the qemuppc64 and qemumips64
(9:43:52 AM) RP_: I'd imagine we'll continue to see aarch64 patches dribbling in
(9:43:55 AM) fray: that would be nice..
(9:44:13 AM) RP_: I think the YP angle on this is we need more
autobuilder hardware
(9:44:24 AM) RP_: but there is a case of adding those machines to OE-Core
(9:44:25 AM) khem: fray: yes I will do provide summary in next TSC
(9:44:27 AM) fray: my concern w/ aarch64 is simply that if we get a
referecne machine (qemu?) then we're going to need autobuilder time
and such.. and new arch's generally find bugs.. :0
(9:44:31 AM) bluelightning: there's the possibility of Qt 5 for 1.5 as well
(9:44:39 AM) bluelightning: I'm still disconnected from that
(9:44:47 AM) bluelightning: but work has been progressing thanks to others
(9:44:52 AM) RP_: fray: someone will have to sponsor AB resources and
some QA to make that happen
(9:44:52 AM) fray: bluelightning ahh.. good point.. I had someone ask
me about Qt 5 the other day as well
(9:45:00 AM) fray: RP_ ok
(9:45:29 AM) RP_: fray: there are some YP members interested in the
other qemu64 I mentioned so those are less of an issue
(9:45:59 AM) fray: So one other thing..  I've mentioned this before
briefly on IRC..  during 1.5, we should look at getting rid of
'native' and moving everything to 'nativesdk'.. remvoe duplication
(9:46:10 AM) RP_: fray: no
(9:46:23 AM) fray: (I have no idea at this point if it's reasonable in
that time frame, but on the surface it looks that way to me)
(9:46:37 AM) RP_: fray: there are some deep technical issues in doing that
(9:46:50 AM) RP_: native assumes the host libc, nativesdk builds its own
(9:46:56 AM) fray: All of the ones I knew of had been resolved..
(9:47:19 AM) RP_: fray: nativesdk is done as a cross, you need the
native tools to support the cross build
(9:47:23 AM) fray: I thoguht we wanted to use the build eglibc to
avoid more problems..
(9:47:41 AM) RP_: fray: no, where did you get than from?
(9:48:06 AM) fray: people complaing that -native's are breaking on
upgrade or trying to reuse sstate between machines
(9:48:15 AM) RP_: fray: didn't we fix that?
(9:48:42 AM) fray: I'm talking about upgrading the host.. not OE-core
(9:48:50 AM) RP_: fray: I know
(9:49:00 AM) fray: if we did fix it, I'm not aware of it
(9:49:15 AM) RP_: We inject the LSB release strings into the sstate location
(9:49:17 AM) fray: (I'm also not completely aware of the problems
people were reporting.. what the actual bugs were)
(9:49:44 AM) bluelightning: which include the version...
(9:49:49 AM) RP_: fray: this sounds like something which needs more
detailed analysis
(9:49:52 AM) fray: "sometimes"
(9:50:02 AM) bluelightning: yes, more details needed
(9:50:05 AM) fray: RP- agree.. only bringing it up as something to
consider at this point
(9:50:24 AM) RP_: fray: I'll just say that merging native and
nativesdk isn't feasible as I understand it at this point
(9:50:34 AM) fray: ok
(9:50:34 AM) RP_: fray: lets talk more about the specific issues in due course
(9:50:43 AM) fray: ok
(9:51:01 AM) RP_: As I mentioned earlier, automation will be a big push in 1.5
(9:51:04 AM) fray: thats it for my 1.5 topic
(9:51:08 AM) RP_: (for QA)
(9:51:28 AM) khem: brb
(9:51:30 AM) RP_: the qemuimagetest infrastructure should adapt
relatively easily to real hardware
(9:51:32 AM) fray: I'd love to see bugs get test cases written for
them as part of hte fix..  but I believe that's only a dream.. ;)
(9:51:49 AM) RP_: fray: we are in fact starting to do this in some areas
(9:51:57 AM) RP_: the fetcher for example now has a test suite
(9:52:02 AM) fray: RP_, I know.. I'm happy to see that
(9:52:24 AM) RP_: fray: I hope we'll see improvements in 1.5 :)
(9:52:49 AM) bluelightning: another thing we've talked about for 1.5
is eliminating the wrapper script (i.e. allowing re-exec within pseudo
within the build process instead of externally)
(9:52:50 AM) RP_: I know deployment is also a big thing for 1.5 -
standalone image generation from feeds and so on
(9:53:05 AM) RP_: which I know we've been able to do berfore but this
would be much enhanced
(9:53:18 AM) RP_: ah, yes. That wrapper script needs to die
(9:53:28 AM) RP_: means changing bitbake internals, not impossible
(9:53:31 AM) fray: that would be -really- nice..
(9:53:41 AM) bluelightning: right, it's not a trivial task, but worthwhile
(9:53:52 AM) RP_: oh, and the second part of this is the performance
improvement if we could leave the bitbake server resident
(9:54:18 AM) RP_: load at source the script time, then commands just
connect to it
(9:54:31 AM) RP_: should make for a lovely responsive set of commands
(9:54:50 AM) fray: (I know I'd love to be able to run bitbake on an
external machine, but have the UI local)
(9:54:58 AM) RP_: fray: you can do that today
(9:55:05 AM) fray: ya, I use SSH.. ;)
(9:55:15 AM) RP_: fray: no, it has options for it over xmlrpc
(9:55:28 AM) RP_: fray: go look at bitbake --help ;-)
(9:55:48 AM) RP_: fray: you do need to use the -t xmlrpc option
(9:55:54 AM) fray: I do regularly..... but documenting this and make
it part of a standard use... would be nice
(9:56:18 AM) RP_: ok, anything else on 1.5?
(9:56:33 AM) RP_: and anything else on the second section 4 which we
can henceforth refer to section 5
(9:56:42 AM) fray: I'm good
(9:57:04 AM) Jefro: :-/
(9:57:15 AM) RP_: I should highlight we've made some serious
performance improvements in 1.4
(9:57:24 AM) RP_: https://wiki.yoctoproject.org/wiki/Performance_Test
(9:58:30 AM) RP_: size on disk is down, overall build time is down,
rm_work removes more, rootfs task is much faster
(9:58:42 AM) RP_: I'm really happy with what we've managed to do there
(9:59:03 AM) RP_: Anything else?
(9:59:28 AM) RP_: If not I will call the meeting closed!

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

Re: [oe] OpenEmbedded TSC 8 April 2013

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

On Tue, Apr 23, 2013 at 02:47:56PM -0700, Jeff Osier-Mixon wrote:
> OpenEmbedded Technical Steering Committee
> 8 April 2013
> 
> 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)

Someone probably noticed, but all meta-openembedded layers are now using
consistent indentation:
http://git.openembedded.org/meta-openembedded/commit/?id=a45830a39bb47a9eab27980d52966226c9504ea4

Can we reevaluate decision to keep styleguide promoting different
indentation for python and shell tasks? Otherwise we should mention
different rules for oe-core and other layers.

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [oe] OpenEmbedded TSC 8 April 2013

[Richard Purdie]

On Wed, 2013-04-24 at 08:43 +0200, Martin Jansa wrote:
> On Tue, Apr 23, 2013 at 02:47:56PM -0700, Jeff Osier-Mixon wrote:
> > OpenEmbedded Technical Steering Committee
> > 8 April 2013
> > 
> > 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)
> 
> Someone probably noticed, but all meta-openembedded layers are now using
> consistent indentation:
> http://git.openembedded.org/meta-openembedded/commit/?id=a45830a39bb47a9eab27980d52966226c9504ea4
> 
> Can we reevaluate decision to keep styleguide promoting different
> indentation for python and shell tasks? Otherwise we should mention
> different rules for oe-core and other layers.

The TSC talked about it and agreed a particular direction. Its clear
that some people don't like the direction so they just ignored it and do
their own thing anyway.

This is the wrong way to go about making decisions and I'm extremely
disappointed people are doing this.

There were specific technical reasons I suggested we not do this. One of
the asks of the Yocto members is some kind of stability, whatever that
is. Whitespace changes like this are *extremely* disruptive to patch
flow. I think its clear there are people out there using older versions
of the codebase yet they pick patches off master and backport them for a
variety of reasons. As soon as you get changes like this involved, it
breaks their ability to do that. With the python change, there was a
good technical reason we did it. Despite that I was personally literally
backed into a corner and shouted at by some rather upset people last
time this happened with the python change. I can see their point too.
For changing shell, we don't have any good technical reason other than
cosmetics. I've made this argument before.

You know what, thanks for the support guys :(

At this point I assume I'm free to ignore the TSC since we now have
precedent for it?

Richard

Re: [oe] OpenEmbedded TSC 8 April 2013

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]

On Wed, Apr 24, 2013 at 09:01:06AM +0100, Richard Purdie wrote:
> On Wed, 2013-04-24 at 08:43 +0200, Martin Jansa wrote:
> > On Tue, Apr 23, 2013 at 02:47:56PM -0700, Jeff Osier-Mixon wrote:
> > > OpenEmbedded Technical Steering Committee
> > > 8 April 2013
> > > 
> > > 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)
> > 
> > Someone probably noticed, but all meta-openembedded layers are now using
> > consistent indentation:
> > http://git.openembedded.org/meta-openembedded/commit/?id=a45830a39bb47a9eab27980d52966226c9504ea4
> > 
> > Can we reevaluate decision to keep styleguide promoting different
> > indentation for python and shell tasks? Otherwise we should mention
> > different rules for oe-core and other layers.
> 
> The TSC talked about it and agreed a particular direction. Its clear
> that some people don't like the direction so they just ignored it and do
> their own thing anyway.
> 
> This is the wrong way to go about making decisions and I'm extremely
> disappointed people are doing this.
> 
> There were specific technical reasons I suggested we not do this. One of
> the asks of the Yocto members is some kind of stability, whatever that
> is. Whitespace changes like this are *extremely* disruptive to patch
> flow. I think its clear there are people out there using older versions
> of the codebase yet they pick patches off master and backport them for a
> variety of reasons. As soon as you get changes like this involved, it
> breaks their ability to do that. With the python change, there was a
> good technical reason we did it. Despite that I was personally literally
> backed into a corner and shouted at by some rather upset people last
> time this happened with the python change. I can see their point too.
> For changing shell, we don't have any good technical reason other than
> cosmetics. I've made this argument before.

Hi,

I'm sorry you feel that way about it, I'll try to make it a bit better:

1) it was discussed and acked by major meta-openembedded contributors
and maintainers:
http://lists.linuxtogo.org/pipermail/openembedded-devel/2013-April/044989.html

2) it was done just before we'll branch dylan, so that backporting issue
is only for people backporting over 2 releases (from after-dylan-master
to danny). And even if someone gets whitespace wrong in backport, then
there is no real harm, because as you say, it's only cosmetic now and
meta-openembedded layers were very inconsistent about it (tabs were used
only in minority of recipes).

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [oe] OpenEmbedded TSC 8 April 2013

[Phil Blundell]

On Wed, 2013-04-24 at 09:01 +0100, Richard Purdie wrote:
> The TSC talked about it and agreed a particular direction. Its clear
> that some people don't like the direction so they just ignored it and do
> their own thing anyway.
> 
> This is the wrong way to go about making decisions and I'm extremely
> disappointed people are doing this.

It's maybe worth pointing out that this change was discussed on the
mailing list at the time.  During that thread, two members of the
TSC spoke in favour of the change and neither they nor anybody else
pointed out that it was contrary to the TSC's stated policy. 

So, although I agree it is a bit unfortunate that meta-oe has decided
to go off and plough its own furrow, it doesn't seem that the TSC made
much of an effort to dissuade them at the time and I can understand how
Martin might have interpreted the responses he got as approval.

>At this point I assume I'm free to ignore the TSC since we now have
>precedent for it?

As far as I know you've always been free to do that.  It's up to the TSC
to enforce its own decisions if it wishes to.

All that said, I have had a suspicion for a while that the TSC is
perhaps becoming superfluous to requirements.  When the TSC was first
set up, the environment within which OE operated was very different:
this was a time before the Yocto Project and before oe-core, when
everything was in a single tree, a vast number of people had
indiscriminate commit access, and there was no identified maintainer who
was empowered to make decisions about which patches went in and which
didn't.

Nowadays it seems (and I don't intend this as a criticism) that most of the
technical direction is coming from the Yocto side and the OE project
itself is mostly just going along for the ride.  Plus, every layer does
now have its own maintainer so the original power vacuum that the TSC
was created to fill no longer exists.  In this sort of scenario it seems
as though OE is rather over-equipped with governance mechanisms (the
TSC, the e.V. board and the e.V. membership itself) that aren't
necessarily accomplishing very much.

Also, now that we have a multiplicity of layers rather than a single
monolithic tree, it isn't entirely obvious where the TSC's authority
begins and ends.  I think everyone would agree that oe-core falls under
the aegis of the TSC, but beyond that it isn't totally obvious which
layers do and don't count as part of "OE" for that purpose.

And finally, it's been apparent during the last few TSC and board
elections that it is a bit of a struggle to attract high-quality
candidates to stand for membership of either body.  I don't think we've
had an election which was actually contested for quite some time: this
makes the elections themselves seem like just a waste of everybody's
time.

So, maybe it's time that we as a project had a bit of a re-think
regarding what sort of governance structures we actually need and want
in this day and age.

p.

Re: [oe] OpenEmbedded TSC 8 April 2013

[Richard Purdie]

On Wed, 2013-04-24 at 11:39 +0100, Phil Blundell wrote:
> It's maybe worth pointing out that this change was discussed on the
> mailing list at the time.  During that thread, two members of the
> TSC spoke in favour of the change and neither they nor anybody else
> pointed out that it was contrary to the TSC's stated policy. 

I read it as one backing, the other made some clarifications on some
comments rather than saying they were (or were not) in favour. 

> So, although I agree it is a bit unfortunate that meta-oe has decided
> to go off and plough its own furrow, it doesn't seem that the TSC made
> much of an effort to dissuade them at the time and I can understand how
> Martin might have interpreted the responses he got as approval.

The TSC as a whole was not aware of this or some of its other members
may have been more vocal. Unfortunately I don't manage to read as much
of the oe-devel list as I'd like, particularly around things like the
current release.

> >At this point I assume I'm free to ignore the TSC since we now have
> >precedent for it?
> 
> As far as I know you've always been free to do that.  It's up to the TSC
> to enforce its own decisions if it wishes to.

FWIW I've always tried to respect the TSC as the decision making body
for the OE architecture. 

The fact we've not had to really test "TSC Enforcement" is probably a
sign that we've managed many things well as a project and should be
taken as a positive.

> All that said, I have had a suspicion for a while that the TSC is
> perhaps becoming superfluous to requirements.  When the TSC was first
> set up, the environment within which OE operated was very different:
> this was a time before the Yocto Project and before oe-core, when
> everything was in a single tree, a vast number of people had
> indiscriminate commit access, and there was no identified maintainer who
> was empowered to make decisions about which patches went in and which
> didn't.

Certainly times have massively changed and some of the issues that used
to exist are now very different.

> Nowadays it seems (and I don't intend this as a criticism) that most of the
> technical direction is coming from the Yocto side and the OE project
> itself is mostly just going along for the ride.  Plus, every layer does
> now have its own maintainer so the original power vacuum that the TSC
> was created to fill no longer exists.  In this sort of scenario it seems
> as though OE is rather over-equipped with governance mechanisms (the
> TSC, the e.V. board and the e.V. membership itself) that aren't
> necessarily accomplishing very much.

Whilst times have changed, the fundamental problem with OE could be
distilled down to "How can OE make a decision?". The agreement reached
was that the membership elect two bodies, one effectively administrative
and the other a technical one who between then guide the project between
them.

I don't think that problem has changed. The mechanics of how code gets
developed has but ultimately, OE still needs to be able to make
decisions. Whilst the Yocto Project specifically adopted the
"OpenEmbedded Architecture", it has worked hard to try and ensure that
OE does continue to reflect what it always has. Its a complex balancing
act but I think its been a net positive for everyone.

> Also, now that we have a multiplicity of layers rather than a single
> monolithic tree, it isn't entirely obvious where the TSC's authority
> begins and ends.  I think everyone would agree that oe-core falls under
> the aegis of the TSC, but beyond that it isn't totally obvious which
> layers do and don't count as part of "OE" for that purpose.

I guess the ideas around "Yocto Project Compatible" are the YP's
approach to some of those questions although it clearly doesn't address
things from an OE perspective.

For the record I'd also state I don't think it wise to try and stifle
innovation. I sometimes worry we do seemingly end up doing that although
it has never been anybody's intent. It is ok to do something
differently, experiment and innovate. Equally I do hope we can
ultimately maintain one great ecosystem rather than having multiple
semi-incompatible competing components so a natural pressure for
compatibility is a good thing.

> And finally, it's been apparent during the last few TSC and board
> elections that it is a bit of a struggle to attract high-quality
> candidates to stand for membership of either body.  I don't think we've
> had an election which was actually contested for quite some time: this
> makes the elections themselves seem like just a waste of everybody's
> time.
> 
> So, maybe it's time that we as a project had a bit of a re-think
> regarding what sort of governance structures we actually need and want
> in this day and age.

The problem of "quality candidates" also applies to layer maintainership
in general and submaintainers for OE-Core itself. I've talked about this
a lot with people in person but probably not much on list. Basically I'd
love to have more people acting as dedicated maintainers for areas,
collecting up patches and so on. I scale really badly. The trouble is
the role of layer maintainer is a lot of work and pretty thankless so
attracting those quality candidates is hard. Its not something you can
dip into and out of, its a pretty hefty commitment. People often only
want the positive parts, not the dull work.

The TSC has become less of a decision making body and more an interest
group which meets and tries to help the various parts of the project
keep moving and on track to the best interests of everyone. It struggles
as there is nobody the TSC can delegate "work" to other than its own
members. Those members do a lot of random things for the project which
do make a significant difference but are not the "technical decision"
remit of the TSC role (e.g. Paul's work in cleaning up the OE wiki). The
changes there were significant and possibly needed to be TSC sanctioned
however the TSC members ended up doing the work too. I think its good
work, the TSC also gives some oversight to the maintainership of OE-Core
so there is value there. Whether it now needs refactoring and into what
form, I don't know.

At this point I'd be interested to hear from others and to hear
proposals for what we do going forward.

I'd note that my seat on the TSC is due for re-election shortly too with
the process starting next month.

We are at an interesting point with the project. There are a lot of new
people using the system and slowly becoming more involved and more
knowledgeable. Many newcomers aren't probably ready to take on
maintainership roles or TSC seats right now. The position could be very
different in say 24 months time...

Cheers,

Richard