OE TSC Minutes 7 May 2013

OE TSC Minutes 7 May 2013

[Jeff Osier-Mixon]

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

Re: OE TSC Minutes 7 May 2013

[Martin Jansa]

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

On Tue, May 21, 2013 at 12:36:54PM -0700, Jeff Osier-Mixon wrote:
> 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

I really like this idea, I think it will improve situation with:
status updates - people can watch it immediately on IRC, instead 
  of waiting for minutes
lack of community input - easier for people to comment on issues or add
  to agenda when they see discussion about related topic
community involvement - seeing some AR discussed a month ago is too late
  to volunteer

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

p3-only looks good to me, I would be happy to help testing this and then
drop p2 from my minimalistic chroot. There are also some external tools
like opkg-utils (IIRC this one is 99% p3 compatible now, I can take care
of remaining).

> (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?

I like them.

> (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?

For many recipes I've used meta-shr as "staging" area to test it on more
builders and probably by more people before moving them to meta-oe.

But it's also easy to forget them in "staging" area, when they just
work for me (as I have meta-shr always included) and nobody shows any 
interest in them.

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

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

Re: OE TSC Minutes 7 May 2013

[Andreas Müller]

On Tue, May 21, 2013 at 9:36 PM, Jeff Osier-Mixon <jefro@jefro.net> wrote:
> 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]
>
There are three issues I would like to comment on:

1. systemd migration:

From what I see the only major step left over is to bury meta-systemd.
The only appends found there are those for oe-core. I asked for this
long time ago [1] and support was offered but...

2. indention:
Reading between the lines there is some unhappiness on meta-oe using
four spaces for shell and python code. I personally agree with Martin
here because I have not seen a technical reason for shell requiring
tabs so far. To me this looks like a style decision which increases
the burden to submit for low-skilled people like me. Could somebody
please enlighten me: For what technical reason do we need tabs in
shell code?

3. xserver-nodm-init oe-core vs. meta-oe
This is a long lasting issue and Martin commented on why there is a
different approach in meta-oe [2]. One blocker for progress is xinput
calibrator rework. Short story: I have a solution working here which
is capable of starting calibrator by udev/systemd and can be invoked
by an unprivileged user at any time. Unfortunately this solution has
still too many issues to be submitted and from what I see now I won't
find the time to fix them in the next future. So if anybody wants to
unify xserver-nodm-init - feel free. Users can add xserver.common to
images manually (and xinput calibrator is not really working anyway).

If I could I would add an additional item on the agenda:

gtk3-migration:
In meta-gnome we are working with terribly old gnome recipes. These
needed much backporting efforts to survive glib-2.36 / gcc 4.8 updates
- and I don't think this increases code quality in any way - so it is
more or less a useless effort which we will continue.

* Are there plans for a step-by step migration? A good starter would
be to solve libnotify 2/3 API issue. Is anybody else working on this /
thinking about?
* Are there plans to update gtk3 to 3.8.x to have wayland support?

Cheers

Andreas

[1] http://lists.openembedded.org/pipermail/openembedded-core/2013-January/073596.html
[2] http://lists.openembedded.org/pipermail/openembedded-core/2013-February/075336.html

Re: [oe] OE TSC Minutes 7 May 2013

[Burton, Ross]

On 22 May 2013 09:31, Andreas Müller <schnitzeltony@googlemail.com> wrote:
> 1. systemd migration:
>
> From what I see the only major step left over is to bury meta-systemd.
> The only appends found there are those for oe-core. I asked for this
> long time ago [1] and support was offered but...

This is a 1.5 goal, and will be getting around to it but I'm also
going on holiday in the first week of June, so if you want to send
patches before I get to it them you're more than welcome.

> * Are there plans to update gtk3 to 3.8.x to have wayland support?

Yes, another 1.5 feature I own.  I have most of the pieces around now.
 If anyone has a ARM or PPC board to immediate hand, then doing a
configure of at-spi2-core and at-spi2-gtk on the devices to get the
right alignment values (yet more alignment checks in configure.ac)
would be incredibly useful.

Ross

Re: [oe] OE TSC Minutes 7 May 2013

[Andreas Müller]

On Wed, May 22, 2013 at 12:31 PM, Burton, Ross <ross.burton@intel.com> wrote:
> On 22 May 2013 09:31, Andreas Müller <schnitzeltony@googlemail.com> wrote:
>> 1. systemd migration:
>>
>> From what I see the only major step left over is to bury meta-systemd.
>> The only appends found there are those for oe-core. I asked for this
>> long time ago [1] and support was offered but...
>
> This is a 1.5 goal, and will be getting around to it but I'm also
> going on holiday in the first week of June, so if you want to send
> patches before I get to it them you're more than welcome.
>
>> * Are there plans to update gtk3 to 3.8.x to have wayland support?
>
> Yes, another 1.5 feature I own.  I have most of the pieces around now.
>  If anyone has a ARM or PPC board to immediate hand, then doing a
> configure of at-spi2-core and at-spi2-gtk on the devices to get the
Haven't found at-spi2-gtk. Do you mean at-spi2-atk?

Andreas

Re: [oe] OE TSC Minutes 7 May 2013

[Burton, Ross]

On 22 May 2013 12:01, Andreas Müller <schnitzeltony@googlemail.com> wrote:
> Haven't found at-spi2-gtk. Do you mean at-spi2-atk?

Yes, typo, sorry.

Ross

Re: [oe] OE TSC Minutes 7 May 2013

[Martin Jansa]

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

On Wed, May 22, 2013 at 09:02:39AM -0500, Mark Hatle wrote:
> (Background) When the spacing was decided, looking at the existing OE recipes 
> and classes, the majority of things were indented such that python used tabs, 
> and recipe (shell scripting) used spaces.  During the cleanup of the scripting 
> sections it was decided that the least impact to all was desirable.  Thus the 
> python-tab, shell-spaces convention.

"python used tabs, and recipe (shell scripting) used spaces"
"python-tab, shell-spaces convention" 

... 

you have it WRONG

> It's true that shell scripts don't really care about indenting, so the four 
> spaces is just a convention that was decided on based on that.  The concern is 
> that if we go in and change the convention now, it's going to cause a lot of 
> potential disruption.
> 
> So the answer isn't that it's a technical reason, it's a community reason. 
> Don't rock the boat on something that is just going to annoy people and provide 
> no actual help.  So far I haven't seen a compelling argument to change the 
> convention BTW, other then (paraphrase) "I don't like spaces, and want to use 
> tabs".  (Note, when I write shell scripts, I prefer tabs as well..)

layers in meta-oe repo were using tabs in less shell tasks then some
amount of spaces.

Using combination of tabs and spaces in the same file (and even on the
same lines) is quite bad, because it looks different based on tab length
and can show wrong indentation in case like 8 spaces and 2
4-character-wide tabs on next line (where author was seeing 18 spaces on
2nd line)

It was acked by 2 TSC members:
Koen: http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/090162.html
Khem: http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/090203.html

3rd member of TSC and maintainer of some meta-oe layers, was aware of this change 
and wasn't complaining:
Paul: http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/090184.html

Joe who also maintains layer in meta-oe repo agreed that it's good idea:
http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/090181.html

Otavio also contributes a lot and agreed with that change:
http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/090146.html

Andreas is sending also lot of patches and formally supported that
change now.

You on other hand don't even follow meta-networking/MAINTAINERS file
when sending patches...

When this was discussed about a year ago in TSC, the most important
reason was complicating backports, you can read something about it my RFC:
http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/090135.html
Now close to creating dylan branch for meta-openembedded is imho best
time to do this, not many changes from released dylan will be backported
to danny, because people will start moving to newer release instead of
backporting more and more stuff to old one (also resolving possible
whitespace merge conflict it not hard). Causing conflicts for merge was
IIRC most important reason why my proposal was rejected for oe-core.

Original proposal here
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026176.html
was also supported by
Chris http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026201.html

Since the change I had to manually update only 6-10 patches submitted for
meta-oe and backporting patches from dylan to danny or denzil is not
influenced by this change.

And TSC minutes which discussed it say:
Reluctant conclusion: tabs for shell, 4 spaces for python.

So please stop trying to show it as action of one maintainer who
decided to go against TSC decision and to scr3w everybody.

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

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

Re: [oe] OE TSC Minutes 7 May 2013

[Paul Eggleton]

On Wednesday 22 May 2013 16:49:25 Martin Jansa wrote:
> Using combination of tabs and spaces in the same file (and even on the
> same lines) is quite bad, because it looks different based on tab length
> and can show wrong indentation in case like 8 spaces and 2
> 4-character-wide tabs on next line (where author was seeing 18 spaces on
> 2nd line)
> 
> It was acked by 2 TSC members:
> Koen:
> http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/09016
> 2.html Khem:
> http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/09020
> 3.html
> 
> 3rd member of TSC and maintainer of some meta-oe layers, was aware of this
> change and wasn't complaining:
> Paul:
> http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/09018
> 4.html

I didn't feel like I had good reason to object other than what had already 
been discussed. That should not be construed as me supporting the move. I now 
regret not commenting further at the time.

The problem is we now have a split between how shell function indentation is 
done in OE-Core and how it is done elsewhere, which as I'm sure you can 
understand is also a suboptimal situation.
 
> When this was discussed about a year ago in TSC, the most important
> reason was complicating backports, you can read something about it my RFC:
> http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/090135
> .html Now close to creating dylan branch for meta-openembedded is imho best
> time to do this, not many changes from released dylan will be backported to
> danny, because people will start moving to newer release instead of
> backporting more and more stuff to old one (also resolving possible
> whitespace merge conflict it not hard).  Causing conflicts for merge was
> IIRC most important reason why my proposal was rejected for oe-core.

We've been through this with OE-Core. We do do a significant number of 
backports and it has been painful when whitespace has changed. The TSC 
decision was taken in order to avoid this.

> And TSC minutes which discussed it say:
> Reluctant conclusion: tabs for shell, 4 spaces for python.
> 
> So please stop trying to show it as action of one maintainer who
> decided to go against TSC decision and to scr3w everybody.

The problem with this is that you've effectively added pressure on Richard to 
change the the policy in OE-Core despite the explicit decision not to make 
this change there.

This kind of overall policy change *must* be done everywhere and not just in 
one place or even the majority of places. We shouldn't ever need to be in a 
position where OE-Core says you must do one thing and meta-oe and other layers 
say you must do the opposite.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [oe] OE TSC Minutes 7 May 2013

[Martin Jansa]

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

On Wed, May 22, 2013 at 04:11:02PM +0100, Paul Eggleton wrote:
> On Wednesday 22 May 2013 16:49:25 Martin Jansa wrote:
> > Using combination of tabs and spaces in the same file (and even on the
> > same lines) is quite bad, because it looks different based on tab length
> > and can show wrong indentation in case like 8 spaces and 2
> > 4-character-wide tabs on next line (where author was seeing 18 spaces on
> > 2nd line)
> > 
> > It was acked by 2 TSC members:
> > Koen:
> > http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/09016
> > 2.html Khem:
> > http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/09020
> > 3.html
> > 
> > 3rd member of TSC and maintainer of some meta-oe layers, was aware of this
> > change and wasn't complaining:
> > Paul:
> > http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/09018
> > 4.html
> 
> I didn't feel like I had good reason to object other than what had already 
> been discussed. That should not be construed as me supporting the move. I now 
> regret not commenting further at the time.

I didn't say that you supported that, just that you was aware and didn't
complain about it being such a bad idea.

> The problem is we now have a split between how shell function indentation is 
> done in OE-Core and how it is done elsewhere, which as I'm sure you can 
> understand is also a suboptimal situation.

The split was there before too, because more recipes were using some
number of spaces than recipes using tabs "correctly".

> > When this was discussed about a year ago in TSC, the most important
> > reason was complicating backports, you can read something about it my RFC:
> > http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/090135
> > .html Now close to creating dylan branch for meta-openembedded is imho best
> > time to do this, not many changes from released dylan will be backported to
> > danny, because people will start moving to newer release instead of
> > backporting more and more stuff to old one (also resolving possible
> > whitespace merge conflict it not hard).  Causing conflicts for merge was
> > IIRC most important reason why my proposal was rejected for oe-core.
> 
> We've been through this with OE-Core. We do do a significant number of 
> backports and it has been painful when whitespace has changed. The TSC 
> decision was taken in order to avoid this.

Advantage with this is that if you backport patch with different whitespace,
worse you can cause is few spaces in shell task in danny recipe.

> > And TSC minutes which discussed it say:
> > Reluctant conclusion: tabs for shell, 4 spaces for python.
> > 
> > So please stop trying to show it as action of one maintainer who
> > decided to go against TSC decision and to scr3w everybody.
> 
> The problem with this is that you've effectively added pressure on Richard to 
> change the the policy in OE-Core despite the explicit decision not to make 
> this change there.
> 
> This kind of overall policy change *must* be done everywhere and not just in 
> one place or even the majority of places. We shouldn't ever need to be in a 
> position where OE-Core says you must do one thing and meta-oe and other layers 
> say you must do the opposite.

That's why I was asking to change styleguide and allow new metadata to
be submitted with spaces, as it's only aestetic so changing styleguide
wouldn't force to change every recipe (the same as many recipes having
RDEPENDS next to DEPENDS instead of near the end of file next to
do_package and FILES_ etc.). 

Cheers,

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

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