<div>Minutes: OE-TSC meeting 13-December-2011</div><div><br></div><div>Attending: Richard, Tom, Mark, Khem</div><div>Absent: Koen</div><div>Notes in absentia: Jefro</div><div>___________________________________________________</div>
<div>Agenda:</div><div><br></div><div>Chair: Tom</div><div><br></div><div>New issues</div><div>- WR review request template</div><div> WR template as starting point: <a href="http://bugzilla.yoctoproject.org/show_bug.cgi?id=1829">http://bugzilla.yoctoproject.org/show_bug.cgi?id=1829</a></div>
<div> * fray to take a pass at adapting for OE</div><div> * RP to file bugzilla enhancement request (see above link)</div><div><br></div><div>- default source mirror for oe-core</div><div> people using oe-core w/o yocto getting issues with source downloads</div>
<div> suggest oe-core use yocto's autobuilder source mirror as a fallback</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>default will be <a href="http://sources.oe.org">sources.oe.org</a></div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>not appropriate for oe classic</div><div> * khem to take action</div><div><br></div><div>- !gplv3 packages that are not being tested</div><div> request yocto do occasional build without gplv3</div>
<div> * fray to check with WR test team, file bugzilla enhancement req</div><div><br></div><div>- documentation</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>wiki now has easier-to-admin turing test</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>tag instructions as oe-classic & review, header at top of page</div><div> * fray & khem to work on reviewing, reach out to person suggesting wiki revs</div>
<div><br></div><div>- autobuilder/regressions</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>patch review process onerous for trivial fixes</div><div> * further discussion necessary</div><div><br>
</div><div>Status</div><div>- TSC elections</div><div> board issue, TSC happy to assist when necessary</div><div><br></div><div>Next meeting: Jan 3</div><div>___________________________________________________</div><div>
Raw Transcript:</div><div><br></div><div>Tuesday, December 13, 20119:47mode (+v Tartarus ) by ChanServ</div><div>9:47 Tartarus ~13min?9:49 RP__ Tartarus : yes</div><div>9:57 fray hey there a meeting right now?(or well, in 3 minutes)?</div>
<div>9:59 RP__ fray : YESer, yes</div><div>9:59 fray hehlets see if everyone else remembered..</div><div>9:59 Tartarus No khem yet and koen is doing something today</div><div>10:00 fray is 3 a quorem or do we need 4?</div>
<div>10:00 Tartarus 3 is iirc</div><div>10:00 RP__ 3 is a quorum</div><div>10:00 fray ok.. couldn't remember since we dropped form 6 to 5</div><div>10:01 RP__ fray : we were always meant to be 5no deadlock</div>
<div>10:01 Tartarus So, agenda?</div><div>10:01 RP__ we miss Jefro</div><div>10:01 fray the only thing I had was to show off the WR review request</div><div>template.. (no action required.. just wanted to show it off so we had</div>
<div>something if we determined it as necessary)</div><div>of course needs to find the template and pass it on. (If we want to do this)</div><div>10:02 RP__ Anything we need to cover re: the incident with the mailing</div>
<div>list subscriptions? fray : probably a good topic when we have more</div><div>people</div><div>10:02 fray Ya.. I'm fine with delaying it..</div><div>10:02 Tartarus re the ML stuff, no, I think that's handled</div>
<div>10:02 RP__ Tartarus : ok</div><div>10:03 RP__ Anything re: TSC elections?</div><div>10:03 fray IMHO it's the type of thing we might need if stability of the</div><div>patches goes down -- or more people question the stuff..</div>
<div>10:03 Tartarus I don't really know why it would be a TSC thing, aside</div><div>from koen being a member, fwiw</div><div>10:03 RP__ Tartarus : Some people I've talked to suggest its a TSC issue, some says its the board</div>
<div>10:03 fray Tartarus I think thats the only thing</div><div>10:03 RP__ It was actually reported to the TSC first, I referred it to a</div><div>wider group(falls to the TSC as a conflict between members than needed</div>
<div>resolving)</div><div>10:04 khem [~ khem @<a href="http://99-57-141-118.lightspeed.sntcca.sbcglobal.net">99-57-141-118.lightspeed.sntcca.sbcglobal.net</a>] entered the</div><div>room.10:04mode (+v khem ) by ChanServ</div>
<div>10:04 RP__ hi khem </div><div>10:04 Tartarus hey khem </div><div>10:04 fray in the end I think it's a board issue, that we are "happy" to</div><div>assist in as necessary</div><div>10:04 khem hi RP__ </div>
<div>10:04 fray hey</div><div>10:04 RP__ khem : agenda items?</div><div>10:04 fray w/ khem here, want me to dig up the template or still postpone..</div><div>10:04 khem I would like to discuss default source mirror for oe-core issue</div>
<div>10:05 RP__ khem : ok</div><div>10:05 fray ya, that has been hurting people a lot recently..</div><div>10:05 RP__ fray : could do</div><div>10:05 fray Ohh I do have one other item to mention.. in OE-Core, it</div><div>
appears we have a number of !gplv3 package that haven't been tested in</div><div>a while..</div><div>10:05 RP__ So anything else for the agenda and do we have a chair?</div><div>10:06 fray (more of an observation at this point)</div>
<div>10:06 RP__ fray : We should try and increase coverage on the autobuilder.</div><div>Perhaps file an enhancement request against the autobuilder?</div><div>10:06 Tartarus I'll chair</div><div>10:06 RP__ Tartarus : thanks</div>
<div>10:06 khem Probably we should discuss documentation too</div><div>10:06 fray RP__ ya, thats my suggestion..</div><div>10:07 RP__ fray : not really a TSC issue</div><div>10:07 Tartarus ok, so I see 4 items</div><div>
10:07 RP__ However lets add autobuilder and fixing regressions to the agenda?</div><div>10:07 Tartarus (1) WR template (carry-over) (2) oe-core source mirror</div><div>(3) oe-core !gplv3 stuff (4) docs</div><div>10:07 RP__ will expand when ready</div>
<div>10:07 fray It's only a TSC issue in regards to something that's been</div><div>missed recently..</div><div>10:07 Tartarus ok(5) autobuilder/regressions For (1) lets hold since fray </div><div>has to dig up the template stilland give him the AI to do so(2) khem ,</div>
<div>go on</div><div>10:09 khem lot of people who use oe-core w/o yocto are getting issues</div><div>with source downloads</div><div>I would suggest that we use yocto's autobuilder source mirror as a fallback</div><div>
10:10 fray (ready for #1)</div><div>10:10 Tartarus So w/o poky, you mean?</div><div>10:10 fray khem , I'm not opposed to that..</div><div>10:10 Tartarus And give oe-core a default set of mirrors</div><div>10:10 RP__ does feel that would be helpful since OE doesn't maintain one</div>
<div>itselfand this helps people get going</div><div>10:10 fray my only concern is simply in the past people have been</div><div>concerned that setting Yocto as the default was a problem...</div><div>10:10 Tartarus Only issue I see is does Yocto mind the potential</div>
<div>additionaly bandwidth?</div><div>10:10 RP__ the system is complex enough to use without that added hurdle</div><div>10:11 fray I'm 100% for listing the Yocto (and others if appropriate)</div><div>for mirrors.. but I'm not sure they should be enabled by default or</div>
<div>not</div><div>10:11 khem I think default will be <a href="http://sources.oe.org">sources.oe.org</a></div><div>10:11 Tartarus IMHO, on the technical side, we need a mirror</div><div>10:11 khem and fallback will be <a href="http://yp.org">yp.org</a></div>
<div>10:11 Tartarus If politics become an issue, someone can CNAME</div><div>it10:11 RP__ Tartarus : I'm going to stick my neck out and say we should</div><div>be ok</div><div>10:11 fray Tartarus I agree completely</div>
<div>10:11 fray is this something that reasonable (vetted?) source mirrors</div><div>can be listed in the oe-core distro config files, and then enabled by</div><div>simple settings in the users local.conf?</div><div>10:11 khem hmm I like CNAME waytoo</div>
<div>10:11 RP__ Tartarus : the thing is</div><div>maintaining a mirror is a reasonable amount of work. When we could</div><div>freeload off yocto, I'd suggest we just do that tbh</div><div>10:12 Tartarus RP__ : Right.</div>
<div>10:12 fray I personally have zero problems w/ "freeloading" from Yocto</div><div>as the default.. however, the only technical concern I have is when</div><div>an upstream source does change, how are we going to find it?</div>
<div>10:12 RP__ yocto is looking at involvement in LF infrastructure to</div><div>ensure it an scale too</div><div>10:12 khem fray : if we leave that in default local.conf again I think</div><div>users might not enable it</div>
<div>10:13 Tartarus So, RP__ , would there be a problem having the yocto</div><div>mirror also be reachable at <a href="http://something.oe.org?s/reachable">something.oe.org?s/reachable</a> at/reachable</div><div>as/</div>
<div>10:13 RP__ fray : yocto does run tests on no mirror configurations</div><div>10:13 RP__ Tartarus : I think it would be preferred if we</div><div>could show it was yocto's mirror</div><div>10:13 fray RP__ , ya my concern is more with oe-core.. (I realize Yocto</div>
<div>should have that covered)</div><div>10:13 khem fray : I think we need a bitbake --dont-use-mirrors</div><div>--fetch-all-regardless option</div><div>10:13 RP__ Tartarus : i.e. not hide the fact yocto is helping out</div>
<div>10:13 fray secondary item then.. what about "oe-classic" as that seems</div><div>to be the biggest generator of concern I've been seeing..</div><div>10:13 RP__ khem : MIRRORS="" bitbake foo</div>
<div>10:13 khem and this option could be run once a month or so there we go.</div><div>10:14 Tartarus RP__ : ok So, lets see On the technical side, are we in</div><div>agreement that oe-core should default to a mirror? Or is there still</div>
<div>concern?</div><div>10:14 khem fray : for oe.classic I dont think <a href="http://yp.org">yp.org</a> mirror is</div><div>appropriate since it will not have all the sources it needs</div><div>10:14 fray khem , correct..</div>
<div>10:14 RP__ I think it can be added as a fallback reasonably safely</div><div>10:15 fray is angstrom or someone else capable of being a mirror?</div><div>10:15 Tartarus A mirror for oe classic is another thingFor example,</div>
<div>angstrom has a mirror</div><div>10:15 khem yes angstrom has mirror but its throttled</div><div>10:15 RP__ khem : oe.classic is deprecated though and I'd expect angstrom</div><div>is a good choice there if needed</div>
<div>10:15 Tartarus We're just talking oe-core right now</div><div>10:15 fray ok.. framing this squarly on oe-core.. I'm fine with oe-core</div><div>having a mirror by default.. and the mirror being the yocto project..</div>
<div>10:15 RP__ the main problem is OE-Core</div><div>10:15 khem correct oe-core was my concernfor oe.classic we selectively</div><div>put the sources on sources.oe.orgbut this is an issue for oe.classic</div><div>too as long as the maintenance branch is alive</div>
<div>10:16 Tartarus OKSo, for oe-core we all agree on using the yocto mirror</div><div>by default it sounds like khem , can you take the AI to make the patch</div><div>and post it?</div><div>10:17 fray ya.. with the note that if someone else has an appropriate</div>
<div>mirror (after vetting) we would be willing to add them as well..</div><div>10:17 khem I think for oe-core I would prefer to fallback to <a href="http://yp.org">yp.org</a> if not found</div><div>10:17 fray khem , ya.. this would be a "mirror" not "premirror"</div>
<div>10:17 khem notes his AI</div><div>10:17 Tartarus OK, item 2 closed(3) fray , go on</div><div>10:17 fray <a href="http://pastebin.com/AX0FHGppthis">http://pastebin.com/AX0FHGppthis</a> is our WR internal review form..</div>
<div>10:18 Tartarus Oh, you dug out the template, OK(1) then (3)So WR template</div><div>10:18 fray this template is what is provided as the "0" patch..</div><div>10:18 Tartarus What's the background on this again?</div>
<div>10:18 fray Background -- we were having issues a month or more ago on</div><div>patch quality, what a patch was doing and how they were tested..I</div><div>wanted to offer this as a possible suggestion if this reoccurs..</div>
<div>10:19 Tartarus ok</div><div>10:19 fray obviously this has some WR specific items in it.. but the</div><div>idea is simply expand the "patch 0" email to include commonly asked</div><div>items..</div><div>10:19 RP__ We do already cover some things separately</div>
<div>10:19 fray Yes, this just puts it in one place..</div><div>10:19 khem fray : can we enhance the document in wikiwith this info</div><div>10:19 RP__ i.e. we don't need the diffstat pieces</div><div>10:20 khem <a href="http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded">http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded</a></div>
<div>10:20 fray I find the added/removed/diffstat to be useful.. it stops</div><div>people from doing the 100 patch emails.. and makes them group them</div><div>into more structured pieces.. (this may or may not be desireable)</div>
<div>10:20 RP__ the tested board matrix is nice though</div><div>10:20 khem may be this should be enhanced for oe-core</div><div>10:21 fray Testing Applicable To, and Testing Expected results is used</div><div>by us to build up a unit test matrix for changes..</div>
<div>10:21 RP__ fray : is that a problem we've seen with people sending patches though?</div><div>10:21 Tartarus Yes, this could be useful, perhaps both as a short form</div><div>and a long formie for trivial stuff it's not worth doing the full</div>
<div>matrixBut for more complicated changes</div><div>10:21 fray most changes don't have unit tests.. -- but when something</div><div>comes in that should, we make that chunk be filled</div><div>out..10:22 fray Tartarus exactly.. this template is intended to show</div>
<div>that the developer isn't just throwing out a patch.. but actually did</div><div>some work on it.. trivial patches have most things NOT filled out..</div><div>non-trivial most things have to be filled out</div><div>
10:22 fray (again our internal usage)</div><div>10:22 khem I agree on having a suggested template for OE and put it up</div><div>in docs but I would refrain from any SCM hooks</div><div>10:22 fray "Condition of Submission" is often used when "this has passed</div>
<div>all of my tests so far, but it requires patch XYZ from ... before to</div><div>be useful"</div><div>10:22 RP__ well, SCM hooks would only hurt me the way we're working</div><div>10:23 Tartarus OK, so</div><div>
10:23 khem RP__ : no commit hooks can be put in place for local clones</div><div>10:23 RP__ fray : I think we could reword that better as "Dependencies"</div><div>10:23 Tartarus We all seem to like the concept</div>
<div>10:23 fray if we were to adopt something like this, I would expect the</div><div>create patch script to be updated here..</div><div>10:23 Tartarus and agree it needs adapting to OEWho wants the AI</div><div>there?take a first pass at adapting it to OE usage</div>
<div>10:23 RP__ hides</div><div>10:23 fray RP__ (dependencies is just one of many things there).. other</div><div>uses include "this hasn't been fully vetted yet, and I wanted to make</div><div>it available for folks to test"</div>
<div>10:23 RP__ has enough to do atm</div><div>10:23 fray again.. out usage vs what may or may not be required..1) I</div><div>think we need to decided if any of this is useful for OE-core work..</div><div>10:24 RP__ I think this does need someone to look into it furtheri.e.</div>
<div>see how it would get presented to users</div><div>10:24 fray 2) if it is, we can make a pass at adapting it to our usage</div><div>10:24 khem I agree we need to look more at it.</div><div>10:24 Tartarus Yes, agreement on point 1</div>
<div>10:24 RP__ I think my opinion would depend a lot on the actual</div><div>implementationMight I suggest if nobody here wants to take it., we</div><div>file a bugzilla enhancement?</div><div>10:25 Tartarus Yes, lets try that</div>
<div>10:25 fray The #1 thing for us at WR is this template is a starting</div><div>point for reviews.. not everything has to be filled out.. this isn't</div><div>a paperwork exercise, but a way for the reviewer to get the</div>
<div>information without having to ask additional questions -- to speed up</div><div>understandin and reviews of changes.. (the description of the change</div><div>belongs in the patch, but sometimes the ancilery info on testing,</div>
<div>dependencies, if it's a finished patch or not, etc.. gets lost)</div><div>10:25 Tartarus Can someone take the AI to file the bugzilla enhancement?</div><div>10:26 khem I volunteer fray </div><div>10:26 RP__ In the time we're avoiding discussing this we could probably</div>
<div>have filed it</div><div>10:26 fray RP__ back to your question on the diffstat.. I find it nice</div><div>(internally) cause I can simply review these items and not have to</div><div>look at individual patches to follow the work people are doing..</div>
<div><br></div><div>10:27 RP__ fray : each pull request should have a diffstat already</div><div>10:27 Tartarus heh</div><div>10:27 RP__ and I do look at it</div><div>10:27 fray I can file it, but I'm not sure what to file.. this an</div>
<div>enhancement to the create patch script to incorporate a template?</div><div>10:27 RP__ will file the thing</div><div>10:27 Tartarus Thanks RP__ OK, now item (3) testing the non-GPLv3</div><div>versions of stuff fray ?</div>
<div>10:27 RP__ fray : I assume I can copy that pastebin into the bugzilla?</div><div>10:28 fray RP__ yes.. 'er.. I did miss one thing..can you strip the</div><div>@<a href="http://windriver.com">windriver.com</a> email addr?otherwise it's fine to share</div>
<div>10:28 RP__ fray : yes</div><div>10:28 fray ok.. on to 3..What I found is that it hasn't been run for a</div><div>while, so I got SRC_URI checksum problems.. and a few things the</div><div>upstream location for the components went away..(and without the</div>
<div>oe-core mirror we were discussion before, I couldn't download)</div><div>10:29 Tartarus OKSo, what's the desire here? An occasional autobuild w/ no-V3?</div><div>10:30 fray thats it for me on 3.. I just wanted the TSC to be aware of</div>
<div>the issue so we can make sure !gplv3 continues to work -- or say it's</div><div>not necessary for OE-core.. (which I'd disagree with) ya..</div><div>maintenance as necessary</div><div>10:30 Tartarus Since I assume the yocto autobuilder is still</div>
<div>overloaddedCan WR perhaps set this up as a weekly build internally or</div><div>something?</div><div>10:30 RP__ As I said, file an enhancement bug requesting it be added to</div><div>autobuilder testing</div><div>10:30 khem yeah I would say adding it as once a week/bi-weekly test would be fine</div>
<div>10:30 RP__ OE doesn't do testing of many things due to resources so</div><div>we're really going to have to look at Yocto</div><div>10:31 fray I'm not sure if we can.. I'll take an action to check our</div>
<div>test team to see if htey can</div><div>10:31 Tartarus kAnd file a bugzilla enhancement request asking for an</div><div>occasional yocto build like this?</div><div>10:32 fray I'll take that action as well</div><div>
10:32 Tartarus ThanksI think that wraps up (3)So, (4)Docs</div><div>10:32 khem yeah, I think we need to document oe-core ways more and more</div><div>10:33 Tartarus wiki now has better/easier to administer is-a-human</div>
<div>checks, which is good</div><div>10:33 khem yes it does</div><div>10:33 Tartarus But <a href="http://oe.org">oe.org</a> wiki is still in bad shape, isn't it?</div><div>10:33 khem I think we need to separate out contents which is meant for</div>
<div>oe.classic onlyand tag it so</div><div>10:33 fray did the suggetion to make the pages oe-classic (obsolete) get done?</div><div>10:33 khem I am not aware</div><div>10:33 fray I think that would be a really good idea.. then we (oe users)</div>
<div>can go in and fix items for oe-core..</div><div>10:34 khem So how should it be donesome documents are 80% common between</div><div>classic oe and oe-coreso to update it should we now make it 100%</div><div>oe-core</div>
<div>10:35 fray For policies -- unless specifically against oe-classic they</div><div>should be fine for now.. we should probably review then (as the TSC,</div><div>if appropriate) and verify they are still right</div><div>
10:35 khem or copy it over and create a new document for oe-core</div><div>10:35 fray for the how-to, tag them all oe-classic and then "fix them"</div><div>one by one as possible.. khem , hmm.. I'm not sure</div>
<div>10:35 RP__ doesn't have much to add other than agreeing this needs to be done</div><div>10:35 Tartarus khem : Or just a "For OE Classic" section at the bottom of</div><div>the page?10:36 fray Tartarus that might be a better answer a things</div>
<div>won't be moving then..</div><div>10:36 khem should we have two copies of slightly differing docs</div><div>10:36 Tartarus I don't like that idea, at first pass</div><div>10:36 fray if it were a book, we'd have some market to say (inline) this</div>
<div>is oe-core and this oe-classic.. but I'm not holding my breath on that</div><div>10:37 RP__ <a href="http://bugzilla.yoctoproject.org/show_bug.cgi?id=1829">http://bugzilla.yoctoproject.org/show_bug.cgi?id=1829</a> filed</div>
<div>for the template issue</div><div>10:37 Tartarus Maybe if we end up having lots of, and long sections of</div><div>"For OE Classic"</div><div>10:37 khem since maintenance branch is still alive we sort of need to</div>
<div>have the classic docs</div><div>10:37 Tartarus we do an oe classic namespace</div><div>10:37 RP__ I think some kind of notation pointing out differences with</div><div>OE Classic would be best</div><div>10:37 fray RP__ that would be ideal as it would help people transfer</div>
<div>from one to the other..</div><div>10:37 RP__ and only split the things where its obvious there are big differences</div><div>10:38 khem I think we can add OE-classic-only or something</div><div>10:38 fray We should try to contat the user on the list who offered to</div>
<div>start this work and see if they still can</div><div>10:38 RP__ (submission of patches springs to mind)</div><div>10:38 khem RP__ : new people who go to wiki get intructions for oe.classic atm</div><div>10:38 RP__ I'd try and embrace any help with this</div>
<div>10:38 khem that should change</div><div>10:38 RP__ agreed</div><div>10:39 fray so should we "#1" tag all instructions as oe-classic.. and</div><div>then set out to review them?</div><div>10:39 khem I plan to work on docs myself some</div>
<div>10:39 fray #2 -- who reviews and decides?(my concern this documents</div><div>never being reviewed... better to mark them as oe-classic and then</div><div>give a user the wrong impression.. even if parts hold true for</div>
<div>oe-core)</div><div>10:40 khem fray : how do we make that distinction in wiki</div><div>10:41 RP__ khem : add a header at the top of each page?</div><div>10:41 khem RP__ : yes that would work</div><div>10:41 fray yup.. that was the users suggestion on the list, and I think</div>
<div>it's the right one..they even had a template for itlast I saw, they</div><div>couldn't upload their "circle I" info graphic to implement it though</div><div>10:42 RP__ khem : could you help them with the upload?</div>
<div>10:43 khem RP__ : sure I dont know who it was</div><div>10:43 fray let me find it..</div><div>10:43 khem forward me the mail</div><div>10:43 RP__ People helping with docs should be high on the priority list to attract</div>
<div>10:43 Tartarus OK, since we're nearing the top of the hour</div><div>10:43 fray 12/2/11 4:31AM (Central US time) [oe] Please review my</div><div>tmeplate:Oe-core-transition Wiki entry</div><div>10:43 Tartarus khem , fray , AI to work with the folks with interest in</div>
<div>the community on the wiki?</div><div>10:44 fray Bernhard.guillon@...</div><div>10:44 khem ok</div><div>10:44 fray ya..</div><div>10:44 khem ah yes I remember</div><div>10:44 Tartarus OK, so now item (5)</div><div>10:44 fray <a href="http://www.openembedded.org/wiki/Template:Oe-core-transition">http://www.openembedded.org/wiki/Template:Oe-core-transition</a></div>
<div>10:44 Tartarus autobuilder/patches? RP__ , go on</div><div>10:44 RP__ I don't know if people have noticed or not but I've been</div><div>trying a slightly different approach to some bug fixesBasically, the</div>
<div>overall quality feel of the project has been getting to me a</div><div>bitParticularly when I could watch a build exploding and know how to</div><div>fix it but needing to wait some hours for patch reviewI don't feel too</div>
<div>bad about the fact we're massively managed to improve the stability</div><div>recently but I am worried that people are going to complain about some</div><div>patches not getting proper review So I want to solicit opinions on</div>
<div>what is/is not acceptable</div><div>10:47 fray As the project maintainer.. 1) I think it's reasonable for</div><div>you to put in "trivial" fixes w/o review..2) I think it's reasonable</div><div>for people to complain about non-trivial fixes that didn't get</div>
<div>review..</div><div>10:47 RP__ I do think that whatever we agree needs to be flexible enough</div><div>to allow some judgement as circumstances require</div><div>10:47 fray RP__ yes, I agreepart of being the maintainer, isn't just</div>
<div>being "merge monkey".. but having the knowledge of how and when it's</div><div>appropriate to fix a problem</div><div>10:48 khem RP__ : Do you want to fix badly written patches yourselfand</div><div>reduce the review cycle on fixed patches ?</div>
<div>10:48 fray khem , I think that is a judgement call.. some are worth</div><div>fixing, some aren't</div><div>10:48 RP__ Right, I've also been getting peer review in some cases such</div><div>that if several people knowledgeable in a given area ack it, I'm</div>
<div>prepared to speed it up</div><div>10:48 khem or is it something like you fix a bug which is trivial and</div><div>you want to reduce the review cycle on that</div><div>10:48 Tartarus Well, I can see where you come from, RP__ , but with my</div>
<div>work hat on, on some other projects I've been subjecting myself to the</div><div>same rules as everyone else, for trees I run, on the "I'm not above</div><div>the rules" grounds, and only try and break the rules when there's a</div>
<div>really good reason (usually wrt time to get something out and other</div><div>deadlines)</div><div>10:49 RP__ khem : its the trivial patches that are getting speeded up on</div><div>the most part</div><div>10:49 RP__ Tartarus : right, I don't want to create the</div>
<div>impression I'm above the rules</div><div>10:49 fray to me the deciding factor is should I fix breakage.. I.e.</div><div>I've merged a reasonable patch, but it had an unintended consquence..</div><div>it's logical for me to fix the unintended consquence assuming I (as</div>
<div>the maintainer) deam it to be trivial..</div><div>10:49 Tartarus Right. So for the most part, autobuilder failures are</div><div>annoying, esp when you need to fix something else</div><div>10:50 fray or alternatively decide it's not trivial and back it out</div>
<div>10:50 Tartarus But outside of preparing for releases, is it really a</div><div>win?10:50 RP__ Tartarus : the bigger problem about autobuilder failures</div><div>is when they start masking other issues</div><div>10:50 Tartarus fray , imho, that's what build-before-push is</div>
<div>for10:50 RP__ Tartarus : so we end up with a queue of A hiding B hiding C</div><div>which takes an age to unravel</div><div>10:50 Tartarus RP__ : Right. I'm also used to trigger-by-push</div><div>autobuilders10:50 fray Tartarus yes, I would expect most items are found</div>
<div>in that way.. but occasionally something will slip through</div><div>10:50 khem RP__ : I would propose better testing before putting the patch</div><div>in mastermay be regress master-next more</div><div>10:51 Tartarus And the resources to find B, C and D with my test builds,</div>
<div>and push all the fixes at once</div><div>10:51 fray I think it's reasonable to do this, but it should be avoided</div><div>as much as possible</div><div>10:51 RP__ khem : cycle time on patch review is basically taking too long</div>
<div>for full testing before things go in</div><div>10:51 Tartarus Sadly, I don't even have all of those resources anymore</div><div>10:51 RP__ khem : and the review we have been doing catches say 90% of</div><div>issues. Its the 10% that are causing problems</div>
<div>10:51 fray RP, is part of the problem "full testing" vs "reasonable testing"?</div><div>10:52 RP__ fray : its full testing</div><div>10:52 khem RP__ : throw out the patch</div><div>10:52 fray In my experience full testing takes a long time.. reasonable</div>
<div>testing is fairly short and what most people do to find an issue..</div><div>10:52 khem if it fails the testing on master-nextask it to be redone</div><div>10:52 RP__ khem : so for example the gtk+ demos patch has exposed a</div>
<div>sstate relocation issue in gdk-pixbuf</div><div>10:52 fray khem , only problem is when patches become intertwined that</div><div>isn't as easy to do..</div><div>10:52 Tartarus RP__ : how about thison your machine, how long does it</div>
<div>take to build everything the autobuilder does, image wise, but for</div><div>just one machine/</div><div>10:52 RP__ khem : I know that sstate issue is now "randomly" taking out</div><div>regression test builds khem : how quickly should I merge the fix?This</div>
<div>isn't hypothetical:</div><div><a href="http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/useradd4&id=1d0d6ae267a6900ecbc1eeab36679a9acfd04807">http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/useradd4&id=1d0d6ae267a6900ecbc1eeab36679a9acfd04807</a></div>
<div>10:53 khem RP__ : let autobuilder run on master+your patch</div><div>10:53 RP__ Tartarus : couple of hours</div><div>10:53 fray RP_ this to me falls under the category of existing problem,</div><div>impacting stability.. you have the right to immediately fix it as the</div>
<div>maintainer..but be prepared for blowback if your fix has it's own</div><div>problems</div><div>10:54 khem fray : it does happen</div><div>10:55 RP__ fray : This is the approach I have been taking for some things</div>
<div>10:55 Tartarus RP__ : To me, that says that you should be able to cycle</div><div>over the problems, and get them all fixed, or at least in a better</div><div>spot. And outside of time-critical windows, ML post + a little time</div>
<div>won't hurt</div><div>10:55 khem I think best is to automate somehow to catch these issues in</div><div>process before hand</div><div>10:55 Tartarus A reduced window isn't horrible, either(ie post in the</div>
<div>morning, push in the evening)Looking over at U-Boot for a</div><div>second10:55 RP__ Tartarus : trouble is the above is blocking further</div><div>testing of the BSPs</div><div>10:56 Tartarus Wolfgang posted, and then just pushed, a trivial fix in</div>
<div>~6hall while I was asleep, even if I'm the custodia of the area in</div><div>question</div><div>10:56 RP__ Since we're running out of time I'd suggest we think about this</div><div>10:56 khem yes</div><div>
10:56 RP__ I really just want to raise the fact I'm aware of the issue</div><div>10:56 Tartarus And personally, I know I've made a brown paper bag</div><div>mistake or 20 on trivial I'll just push it now changesSo..</div>
<div>10:57 khem needs to be on road soon</div><div>10:57 Tartarus And yeah, we can conclude this at the next meetingWhich</div><div>will be, um</div><div>10:57 RP__ Tartarus : I don't push anything without local</div>
<div>tests confirming fixes</div><div>10:57 Tartarus 27th? Might not be anyone here, heh</div><div>10:57 fray ya..</div><div>10:57 RP__ heh, that isn't a good time is it</div><div>10:57 khem I wont be here on 27th</div>
<div>10:57 RP__ week later?</div><div>10:57 Tartarus I was going to say, 1 week or 3 weeks?</div><div>10:58 khem after new year yes</div><div>10:58 fray my concluding remarks.. we want to avoid the situation where</div><div>
we have to accelerate a push.. but in the case of an existing bug,</div><div>preventing numerous 'users' from working.. IMHO it's reasonable to</div><div>accelerate a push..</div><div>10:58 RP__ I'm not aware of anything pressing requiring us to meet next week</div>
<div>10:58 fray neither am I</div><div>10:58 Tartarus OK, so Jan 3rd, next meeting?Same time</div><div>10:58 RP__ sounds goodworks for me</div><div>10:58 Tartarus OK, don't forget to update your calendars everyoneI'll</div>
<div>send this log to Jefro </div><div>Which ends HERE</div><div><br></div><div><br></div>-- <br>Jeff Osier-Mixon <a href="http://jefro.net/blog" target="_blank">http://jefro.net/blog</a><div>Yocto Project Community Manager @Intel <a href="http://yoctoproject.org" target="_blank">http://yoctoproject.org</a></div>
<br>