[OE-core] MINUTES: OE TSC 13 March 2012
Jeff Osier-Mixon
jefro at jefro.net
Wed Apr 11 15:04:07 UTC 2012
OpenEmbedded Technical Steering Committee
13 March 2012
Attending:
Richard Purdie (RP)
Paul Eggleton (bluelightning)
Mark Hatle (fray)
Tom Rini (Tartarus)
Khem (khem)
Minutes: Jefro (Jefro)
________________________________________________
Agenda & Summary
1. pick a chair
fray
2. lingering issues
a. raise awareness of "janitor" list, QA "bugs"
item to stand on agenda
=> fray to start publicity about "janitor" bugs
not done yet, waiting for things to calm down this week
3. new issues
a. discuss communication with OE community about
release-oriented phases
=> fray willing to manage page as TSC activity
=> RP to send email updates, TSC to handle in future
=> future agenda: document release process
RP raised awareness at collab
Song sent note to oe-core & yocto lists yesterday
RP talked to Dave & Song about making info more public
=> fray will stay in sync with Dave/RP/Song & create wiki when appropriate
b. mips/mips32 tuning issue
the mips32 tuning has previous produced "mips" tagged packages
[package arch],
and so did the default "mips" tuning. This lead to two
packages with the
same filenames, but very different contents
fray fixed the defect.. which is leading to a concern of a
filename change at the last minute..
=> fray will summarize to list with possible options & ask for comments
4. status
a. elections
board would like to extend for 2 years to avoid election churn
no objections
b. infrastructure
nothing new
c. oe-core release
RP is very worried about the quality of the release and number of open bugs
________________________________________________
Raw Transcript
(8:58:05 AM) Jefro: agenda is at http://pastebin.com/23KsmkGJ
(8:58:45 AM) RP__: hi
(8:58:51 AM) RP__: I'm here put only partially
(8:59:09 AM) RP__: with the release and the conferences and the UK
holidays, I'm stretched today :(
(8:59:13 AM) fray: I'd like a few minutes to talk about the
mips/mips32 tuning issue.. it doesn't have to be under the official
TSC meeting though
(8:59:14 AM) Jefro: 3 1/2 members present then
(8:59:29 AM) Jefro: or is khem back online?
(8:59:52 AM) Jefro: back in 45 sec
(9:00:30 AM) fray: I can flail all I want on this.. but we need a
resolution and a technical decision (maintainer or tsc) IMHO
(9:02:28 AM) Jefro: sounds like an agenda item for tsc
(9:02:45 AM) Jefro: set as 3b
(9:02:46 AM) fray: ya..
(9:02:50 AM) RP__: fray: I was just worried about Phil's reply to your patch
(9:03:06 AM) RP__: fray: Why isn't your description adding up for him?
(9:03:28 AM) fray: Phil isn't the one I'm worried aobut (unless I
missed a response)
(9:03:50 AM) fray: I agree my description is poor and needs to be
revised.. but the contents are one of many possible solutions..
(9:03:59 AM) fray: I could implement them all, but it doesn't make
sense to keep trying this..
(9:04:05 AM) fray: (until I have a specific direction)
(9:04:24 AM) fray: (what I implemented was Khem's suggestion BTW)
(9:04:56 AM) khem: mips1 is default he suggested
(9:05:22 AM) fray: I havn't seen that email then..
(9:05:46 AM) Jefro: should we begin? perhaps counting this discussion in minutes
(9:06:04 AM) fray: we should begin..
(9:06:14 AM) fray: I can quickly recap the discussion as I know it
when we get to 3b
(9:06:19 AM) Jefro: ok, thanks
(9:06:20 AM) Jefro: who wants to chair?
(9:06:28 AM) fray: I'm willing to, if requested
(9:06:33 AM) Jefro: sold
(9:06:53 AM) ***fray loads agenda
(9:06:59 AM) fray: ok.. #1 is done, I've got the honor
(9:07:08 AM) fray: @3 -- janitor list and bugs..
(9:07:11 AM) fray: 'er.. #2
(9:07:25 AM) fray: I have not yet publicised it.. I was waiting for
things to calm down hopefully this week..
(9:07:35 AM) fray: any comments? or on to 3?
(9:07:41 AM) Tartarus: no comments
(9:07:43 AM) fray: (and yes, keep it on the agenda)
(9:07:49 AM) bluelightning: no comments here
(9:08:02 AM) fray: ok.. moving on..
(9:08:09 AM) fray: #3 a -- OS releaste phases..
(9:08:25 AM) fray: again, my work is pending the end of this phase..
(9:08:35 AM) fray: RP -- did you send anything out for the current?
(9:08:48 AM) Jefro: fray - should also poll for any other new business
(sorry, I should put that in the agenda template)
(9:08:57 AM) fray: yes.. sorry
(9:09:10 AM) fray: (any new issues?)
(9:09:24 AM) fray: my request is a brief discussion and resolution to
the MIPS/MIPS32 issue
(9:09:27 AM) fray: (3b)
(9:09:39 AM) bluelightning: don't think I have anything to raise atm
(9:10:02 AM) fray: ok, if anyone thinks of an additional issue, please
speak up.. otherwise back to 3a
(9:10:18 AM) fray: I suspect RP had to step away.. so we can table that part..
(9:10:30 AM) fray: I agree it needs to be kept on the agenda until we
get it decided and completed
(9:10:37 AM) fray: anyone else?
(9:11:07 AM) fray: ok.. on to 3b -- the mips issue
(9:11:22 AM) fray: Let me briefly recap what happened and what the
issue is (as I see it)
(9:12:03 AM) fray: About 2-3 weeks ago, it became clear to me that
(via a PPC issue) that the tunings had become somewhat inconsistent.
So I set about looking for the inconsistencies, correcting them and
documenting the variables used in the tunings. This work was merged
last week as a general cleanup/bug fix..
(9:12:13 AM) RP__: With all the travel I've not really done much with
3a other than raise awareness at collab
(9:12:20 AM) fray: An issue was raided by Andreas Oberritter about the
MIPS "cleanup"....
(9:12:23 AM) fray: RP, thanks
(9:12:43 AM) bluelightning: re 3a also, Song sent out something to the
OE-Core and yocto lists yesterday
(9:13:00 AM) RP__: fray: the issues is that the "mips" package arch
became "mips32"?
(9:13:02 AM) bluelightning: was only an immediate deadlines thing though I think
(9:13:04 AM) fray: ... the mips32 tuning has previous produced "mips"
tagged packages [package arch], and so did the default "mips" tuning.
This lead to two packages with the same filenames, but very different
contents..
(9:13:06 AM) fray: RP -- yes
(9:13:21 AM) RP__: right, I have talked to Dave and Song about making
information more public so Song should be doing more of this
(9:13:28 AM) fray: Andreas is concerned that the changed (near the end
of the release process) to the mips32 RPMs is a problem..
(9:13:31 AM) onoffon [d03605df at gateway/web/freenode/ip.208.54.5.223]
entered the room.
(9:13:31 AM) fray: (back to 3a)
(9:13:54 AM) onoffon is now known as Guest23807
(9:13:55 AM) fray: RP__ ok, I'll make sure I stay in sync with them,
and then publicise this via a wiki page as it comes out..
(9:14:31 AM) fray: I think, once this phase is over, we are going to
have to discuss the exact framework we document for the OE process..
even if it's similar to the Yocto process.. (I see them as
complementary, but perhaps not identical)
(9:15:23 AM) ***RP__ agrees we need to ensure more information is out there
(9:15:32 AM) fray: ok.. anything else on 3a?
(9:15:46 AM) RP__: fray: on the mips vs. mips32 issue, could you send
out a summary and ask for comments?
(9:15:57 AM) fray: I will summarize the thread and do that..
(9:15:58 AM) RP__: fray: I'm also not sure what your last patch does
to change the siutation?
(9:16:12 AM) fray: getting to that.. (if you have a couple more
minutes) I'll get to it here..
(9:16:33 AM) fray: so the defect being discussed is mips and mips32
tunings created files of the same name, but different contents..
(9:16:47 AM) fray: I fixed the defect.. which is leading to a concern
of a filename change at the last minute..
(9:17:06 AM) fray: Possible solutions, revert this part of the fix and
retain the duplicate filenames and fix that "in the future" (I really
don't like that option)
(9:17:17 AM) fray: Keep it "as-is"..
(9:17:37 AM) fray: or what khem suggested, change the "mips"
definition to "mips32".
(9:18:02 AM) fray: (mips previously was using the default "mips"
compiler settings which were "mips1"... as far as we know there are no
real mips1 systems running Linux..
(9:18:21 AM) fray: mips3 or 4 may be the oldest.. but even those are
-very- old systems.. everything these days is mips32 or mips32r2
AFAIK)
(9:18:37 AM) fray: so the last patch I sent was an effort to implement
Khem's suggestion
(9:18:56 AM) fray: (Phil Blundel commented that the description didn't
make sense to him, I agree.. it's poorly worded.. and I'll correct
that)
(9:19:21 AM) fray: but there is a concern now that what happens to
processors then are mips3/mips4 that someone may still be using..
there is no tune for them, and "mips" is no longer compatible.. (I
think)
(9:19:31 AM) fray: ok.. summary for the TSC.. I'll send out something
similar to the list..
(9:19:57 AM) fray: does the TSC have an opinion on this? or is this a
maintainer (RP) decision, or?
(9:20:03 AM) Guest23807 left the room (quit: Ping timeout: 245 seconds).
(9:20:18 AM) Tartarus: Hmm
(9:20:20 AM) RP__: fray: So after these changes, is the package name
"mips" or "mips32" ?
(9:20:41 AM) fray: as it stands now "mips" and "mips32" both get
generated -- after the -last- change I supplied it's now just "mips"
(9:20:51 AM) fray: (last change has not been merged)
(9:21:00 AM) Tartarus: sec
(9:21:08 AM) fray: in the prior freeze, they both generated "mips"..
(9:21:18 AM) fray: only the "mips32" tune is used by oe-core, as part
of qemumips
(9:22:14 AM) Tartarus: I don't know if we really need to worry about
someone using OE on mips3 or mips4
(9:22:25 AM) fray: Tartarus I agree
(9:22:28 AM) Tartarus: We should make sure the tunes are commented
clearly about what they produce
(9:22:42 AM) Tartarus: But not having a tune file that by default is
fine with mips1/3/4 doesn't seem like a big deal
(9:22:54 AM) fray: (the other thing the latest patch did was remove
the "mips32" tune, but left the tune-mips32.inc file in place for
compatibility)
(9:23:26 AM) fray: if someone needs mips3 or mips4.. they can add such
a tune.. it just means "mips4" can't run "mips" packages.. (I don't
see this as a huge problem though)
(9:24:40 AM) Tartarus: So, wait
(9:24:47 AM) Tartarus: We drop mips32 and have 'mips' make mips32?
(9:25:00 AM) fray: yes, that was based on Khem's suggestion
(9:25:37 AM) The account has disconnected and you are no longer in
this chat. You will be automatically rejoined in the chat when the
account reconnects.
(9:26:23 AM) mode (+v Jefro) by ChanServ
(9:26:24 AM) fray: another way to summarize.. in the "last" release..
mips (tune) -> mips (package) and mips32 (tune) -> mips (package) ---
recent change mips (tune) -> mips (package) and mips32 (tune) ->
mips32 (package) -- with the changed based on Khem's suggestion mips
(tune) -> mips (package) and mips32 (goes away)
(9:26:37 AM) fray: (and mips [tune] is now mips32 based)
(9:27:12 AM) Tartarus: yeah, lemme say that back with a different notation
(9:28:05 AM) RP__: I'd suggest this get clearly documented on list and
we was for opinions
(9:28:09 AM) Tartarus: "last" release, mips (tune file) -> mips
(package suffix), mips1 ABI, mips32 (tune file) -> mips (package
suffix), mips32 ABI
(9:28:28 AM) RP__: I'd be particularly interested in Koen's viewpoint
as a distro maintainer with mips packages
(9:28:33 AM) Tartarus: But the end goal of your changes is to have
mips (tune file) -> mips (package suffix), mips32 ABI
(9:28:33 AM) Tartarus: ?
(9:28:53 AM) fray: (ABI is o32 -- the instructions and optimizations
move from mips1 to mips32)
(9:29:20 AM) fray: RP__, ok.. I will write up a summary sent it out,
with possible options..
(9:30:37 AM) RP__: fray: I just think we need a clear summary for
people who've not read/understood the whole thread
(9:30:52 AM) fray: ok. I'll leave it at that then..
(9:30:53 AM) fray: on to 4
(9:31:02 AM) fray: a elections?
(9:31:06 AM) RP__: Then we could make a conscious decision to change
or not. I have a slight preference for mips32 as the packagearch but
only slight
(9:31:08 AM) fray: anything we need to do?
(9:31:23 AM) RP__: I did talk to the board members at collab
(9:31:43 AM) RP__: They mentioned there was a lot of churn with 1 year
elections and they talked about extending people's terms
(9:31:56 AM) RP__: I said that was ok in principle but would really
need to be a direction given by the board
(9:32:06 AM) fray: has everyone been elected now, or is Tom still to go?
(9:32:09 AM) RP__: (people can still decide to step down)
(9:32:31 AM) RP__: Tom is still to go, I suggested they figure out the
term length before the next election
(9:32:52 AM) fray: I do not have an issue with extending the terms..
as long as each of us has gone through an election phase..
(9:33:03 AM) RP__: (term from 1 year to 2 years was the discussion)
(9:33:04 AM) fray: I think it's a disservice to the members otherwise
(9:33:23 AM) fray: RP__ that seems reasonable.. would we offset anyone?
(9:33:39 AM) RP__: fray: well, we have the current offsets
(9:33:43 AM) fray: i.e. have half the group up for election in a year,
the other half in 2.. or are we staggered enough already due to the
current offsets?
(9:33:58 AM) RP__: fray: It would just put off more elections for a
while, particularly when there aren't a queue of people wanting to
join the TSC
(9:34:08 AM) RP__: feeling was staggered enough
(9:34:09 AM) fray: ok.. I see no issue then
(9:34:23 AM) RP__: and we might batch future elections (2 people at a time)
(9:34:32 AM) fray: I could see that being reasonable as well
(9:35:19 AM) fray: ok, any other comments or 4b?
(9:35:23 AM) RP__: Whilst the TSC came up with the process for its
election, I think the board is the right place to make this decision.
I didn't see anything I objected to and I think Khem was present for
the conversation too
(9:35:50 AM) RP__: So this is really just to keep people in the
picture and allow them to talk to the board if they have any concerns
(9:35:51 AM) fray: All I care is that the election process is
staggered in some way..
(9:36:11 AM) fray: ok, moving on then.. 4b infrastructure..
(9:36:13 AM) fray: anything to report?
(9:37:07 AM) RP__: nothing from me
(9:37:26 AM) fray: ok.. I'll move on to 4c
(9:37:33 AM) fray: oe-core release status
(9:37:38 AM) ***Jefro back in 1 minute
(9:39:00 AM) fray: RP__ any updates beyond what Song already sent out?
Are you able to keep up with the pending requests and other items?
(9:42:41 AM) fray: ok.. looks like RP had to step away..
(9:42:50 AM) fray: If there is anything he needs to report, he can do
so to Jefro..
(9:43:07 AM) fray: Any other business or I'll call the meeting over (I
have to get a few thing done in the next 15 mintues)
(9:43:27 AM) Tartarus: looks like the end to me
(9:43:41 AM) Jefro: and so I face the final curtain
(9:43:55 AM) fray: ok.. meeting over -- RP please contact Jefro if
you have anything for the minutes
(9:44:08 AM) ***Jefro will ping him later
(9:45:28 AM) Tartarus: I can send 'em now Jefro if needed
(9:46:06 AM) Jefro: Tartarus sure, send over anything
(9:46:50 AM) Tartarus: sent to your gmail
(9:47:39 AM) Jefro: ah, got it, thanks - I have also been recording
(9:47:48 AM) Jefro: I'll ping RP later for any comments he had on
oe-core release status
...
(9:54:32 AM) RP__: OE-Core status was as per the technical meeting we just had
(9:54:44 AM) RP__: I'm very worried about the quality of the release
and number of open bugs<
--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
More information about the Openembedded-core
mailing list