Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate

#olpc-meeting, 2009-01-29

Index | Today     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
18:03 mchua m_stone: are you around?
18:04 m_stone: it sounds like you have a better handle on the changelog than I do at the moment, so if you are, i was wondering if you might want to chime in on that first.
18:04 (everyone else, http://lists.laptop.org/piperm[…]uary/000762.html)
18:05 cjb oh, hey, there's a meeting
18:05 mchua waves to cjb
18:05 cjb was there an announcement about it?  I think I must've missed it
18:06 mchua cjb: to the testing list, but some things haven't been getting to my inbox recently
18:06 I was kind of surprised when I looked at the archives this morning to start stuffing test results in and found something like 10 emails with results that hadn't hit my inbox before.
18:06 cjb oh, I see it noe
18:06 w
18:07 mchua What I've got on the list for today is     * 1 8.2.1 test results
18:07    * 2 8.2.1 test cycle
18:07    * 3 Testbed and equipment requests
18:07    * 4 Activity (and Sugar) testing moving upstream
18:08 I expect the 1st one to take the most time, 2 and 3 to be pretty fast, and 4 to be a pretty big one since tabitharoder is getting together her legendary crew tomorrow :)
18:09 right now, 8.2.1 QA is the highest priority; m_stone made a great summary email (the link above)
18:09 cjb: do you have any additions to http://lists.laptop.org/piperm[…]nuary/000762.html ?
18:10 tabitharoder yeah, we are here in force this meeting looking at the list, see at least 4 NZers in this meeting
18:11 mchua hullo kimquirk!
18:11 kimquirk hi!
18:12 mchua kimquirk, cjb, m_stone: it sounds like we need wifi and firmware testing the most right now?
18:12 kimquirk we have been doing a lot of that today
18:12 I can summarize what we have found
18:12 mchua kimquirk: that would be awesome
18:13 kimquirk with staging-24 (or 25); q2e29a.rom (which is like q2e30)
18:13 I connected to all types of access points... eventually
18:13 no problems with open APs (no encryption)
18:13 I could connect to the open ones on the first try
18:14 and, after a clean install I could connect to an encrypted AP within one or two tries
18:14 specifically I connected to a WEP, a WPA, and a WPA2 AP
18:15 but only one of them was on the first try
18:15 the others required 2 or even 3 clicks on the AP
18:16 after that I had trouble even re-connecting to WPA2
18:16 after a bunch of trying (5 times, no luck); I rebooted... still couldn't connect, tried 3 more times
18:16 then I removed the networks.cfg file (/home/olpc/.sugar/defaults/nm/networks.cfg)
18:17 rebooted... and it connected the first time to WPA2 access point.
18:17 cjb kimquirk: dsd asked for some more info on the WEP AP that didn't connect immediately, I think he wants logs
18:17 kimquirk so... in summary: WEP, WPA, and WPA has been seen to work... but you need a little persistance and you might have to remove the networks.cfg file
18:17 cjb yeah, here:  http://dev.laptop.org/ticket/9222#comment:9
18:18 kimquirk I would probably have try to recreate that one. It was pretty good compared to the WPA APs
18:18 if it was the case that you really couldn't connect at all; then that is fixed. If it was the case that there is a timing problem and sometimes it works and sometimes it doesn't... it is probably not fixed.
18:19 cjb: not sure I will have time to recreate that one as I am now trying to get 40 laptops up and running on the school server... which do you think is more important (I'll probably only be here another hour or so)
18:20 cjb I agree the XS stuff is more important since WEP works sporadically
18:20 if someone else wants to get us a log of WEP failing and needing more than one click
18:20 that would be pretty helpful!
18:20 kimquirk if the deployments are mostly non-encrypted... then it is painful, but probably not impossible to get a WPA system working
18:21 for the individual (probably g1g1 person)
18:21 do we know of a deployment using encryption?
18:21 btw - the nand blaster is working very well for me right now as I am upgrading 30+ at one time
18:22 mchua certainly doesn't
18:22 wow.
18:22 cjb yes, dsd said he was very happy with the combination of nandblaster and wireless activation he was using
18:23 mchua kimquirk, cjb, m_stone: you folks are way ahead / more on top of 8.2.1 testing than I am; what needs to / can be done to help, given that most of us don't have ready access to an XS or a large testbed right now?
18:23 cjb if we could get peru and uruguay using the same, they'd save a lot of time :)
18:23 m_stone Hi folks.
18:23 just got back from his chocolate run.
18:24 kimquirk hehe -- happy about that! ^
18:24 cjb mchua: Mitch made a good argument last night that he needs people to test his work, but not to follow test plans that specify the things that he already knows to work
18:24 mchua: so I think we probably shouldn't tell you what to test :)  we need a full regression test, I guess
18:24 kimquirk mchua: my desire to come here for testing was to do those things that can't easily be done without a bunch of laptops
18:25 and some of the wifi since there are a bunch of APs set up for that.
18:25 Also, Tom (tjb) was here and got through lots of smoke tests
18:25 m_stone tjb++
18:25 tabitharoder would like test bed and school server to test with
18:25 kimquirk look for the results section on this page: http://wiki.laptop.org/go/Test[…].2.1#Test_results
18:26 cjb heh, now we have tjb, cjb, and cjl.  what could possibly go wrong?  :)
18:26 cr_lf recalls a conv with the Aus/Pacific deployment teams saying encryption and/or system identification was pretty important.
18:26 kimquirk where ever you see buildnumber = 24, that was a test result that Tom added
18:27 I added buildstream 'staging' on my results... as well as build number 24... so you can find the cases that have been tested
18:27 no regression bugs found so far.
18:28 cr_lf: it would be good to get some details from them and also ask them to test this latest build with their encrypted AP
18:28 m_stone kimquirk: indeed, it's been surprisingly well-behaved. (or people have gotten used to the nasty bugs like the memory stuff?)
18:28 kimquirk cr_lf: do you have a contact
18:28 m_stone: I don' t think we have nearly the memory problems we've had in the past (actually some fixes and lots of warnings has really helped)
18:29 cr_lf I do... Ian Thomson was the person who mentioned it so I'll chase him up to clarify what the concern was.
18:29 kimquirk (unless you are thinking of the browser-related ones that some of us just stay away from)
18:29 m_stone kimquirk: yes, those.
18:31 so, in short, we think that staging-25 is just like 8.2.0 but better?
18:31 kimquirk seems like it to me...
18:31 m_stone and we'd really like to know if anyone can disprove that thesis. :)
18:31 kimquirk but i have not looked at the new features... m_stone can help with htat
18:32 m_stone: do you want to summarize what you have been looking at?
18:32 m_stone kimquirk: sure.
18:32 for me, by far the coolest feature in this release is OFW's new multi-key + nand-blaster support.
18:33 see, something that we screwed up when we first set off to do all our security stuff is that we put OLPC on the critical path for software updates.
18:33 that, in retrospect, was not such a great idea.
18:34 we also chose to concentrate on USB sticks rather than on wireless data transmission because we knew that we could make USB sneakernets reliable
18:34 whereas, as you've all seen... wireless has been substantially more difficult.
18:34 so here's the punchline.
18:35 with OFW q2e30, _you_ can take responsibility for deciding what software (kernel, firmware, initramfs) runs on laptops that you administer.
18:35 in fact, you can either augment OLPC's authority (if you want to keep evolving with it directly) or you can trivially override that authority.
18:36 plus, with nand-blaster, (I believe), you can efficiently and security distribute a partition of /your/ choice to all of the laptops in your vicinity that you control.
18:36 kimquirk sounds scarey
18:37 m_stone kimquirk: if by scary, you mean scary-awesome. :)
18:37 kimquirk hehe
18:37 m_stone what I like about this so much is that it only makes the system more flexible than it was before.
18:38 it means that deployments can spend their time actually solving people's problems instead of flashing zillions of XOs by hand with USB sticks.
18:38 kimquirk so, it sounds like we need some awesome release notes for people to be able to use these new features -- and we need to note that ALL laptops show the 'pretty boot' animation now... not just secured laptops.
18:38 tabitharoder From NZ - we would like to know if we can get samples of the hardware used for providing wifi in the sticks
18:38 m_stone kimquirk: yeah, the release notes are going to be a joy to write. :)
18:38 cjb tabitharoder: I don't think we're making those any more, but might be wrong
18:39 m_stone tabitharoder: I didn't quite understand what you meant to say. could you rephrase?
18:39 kimquirk I was kind of hoping mchua might help with that since she was asking about what she could do :-)
18:39 cjb m_stone: I think Tabitha meant the active antennas
18:39 EKML Currently in NZ
18:40 kimquirk mchua: (do you have time to help with release notes?)
18:40 mchua kimquirk: yes.
18:40 tabitharoder Mel - we discuss this later? Martin may have antennas?
18:40 m_stone tabitharoder: nand-blaster is usually used from an XO.
18:40 EKML Currently in NZ-Welly testing, we're running off a laptop running in ad-hoc mode, we don't really the same gear they use in deployments, it would be good to use the same gear - or at least the same kind of gear used in deployments
18:40 m_stone I believe, but am not certain, that it can also be used with some access points.
18:40 mchua kimquirk, m_stone, cjb: while you folks were talking about your test results I was looking and trying to make my own 8.2.1 todo summary.
18:41 kimquirk, m_stone, cjb: how does http://wiki.laptop.org/go/User:Mchua/Sandbox look? (need to fold into the main test case page)
18:41 cjb EKML: sorry, same gear for achieving what?
18:41 tabitharoder we are using my macbook for internet connection through 3g aircard, or using simple mesh
18:41 cjb we had these "active antennas" once, but OLPC no longer sells them
18:41 EKML It's not the antennas, but the AP's
18:42 m_stone tabitharoder: the http://wiki.laptop.org/go/Mult[…]NAND_FLASH_Update only discusses using an XO as the sender...
18:42 cjb EKML: okay.. what kind of AP do you need?  our deployments all use different APs, whatever they can find locally.
18:42 mchua in general, the test case system has been bugging me more and more this cycle, and people have been reporting stuff on the mailing list... kimquirk, I see you and tjb were using it though, should we keep doing that?
18:42 m_stone mchua: this is an extremely short cycle with very few bugs.
18:42 EKML cjb: Ah ok, so they are random AP's hanging around?
18:42 m_stone the TCM would make more sense for a longer release cycle.
18:43 kimquirk I'm not going to be able to help keep it up, so if there is an alternative that lets us track things over time... that is worth exploring
18:43 cjb EKML: I'm still not really sure what you mean, but yes, our deployments each use whatever APs they prefer
18:43 they're just access points, no magic here.
18:43 kimquirk if we really don't even have enough people to do anything other than send emails about what tests were done... then we'll have to do that.
18:43 EKML Ah, ok
18:43 mchua m_stone, kimquirk: yeah, I was writing up http://wiki.laptop.org/go/User:Mchua/Sandbox because I found m_stone's email + that to be a more useful/readable format for me to figure out what needs to be done
18:43 EKML cjb: That answers that question then,.
18:43 tabitharoder we good now?
18:43 EKML Yeah
18:43 cjb EKML: Cool, okay.
18:44 m_stone (actually, for the record, the irc conversation at the bottom of the http://wiki.laptop.org/go/Mult[…]NAND_FLASH_Update page does discuss using the nand-blaster technologies with servers and APs...)
18:44 so maybe that can be explored in the future.
18:45 so, do we have more stuff scheduled for the next 20 minutes?
18:45 tabitharoder We are always looking for a bit of direction on what testing is required - so any requests is our question every week
18:45 m_stone cause if not, I have some things that I'm curious about that I think some of you might have opinions on...
18:45 mchua none this important.
18:45 kimquirk mchua: I'm ok if you want me to update a wiki page with summary of test results...I was just using the test cases since I knew about them and how to.
18:45 mchua m_stone: the other things on the list were...
18:45 #
18:45 # 2 8.2.1 test cycle
18:45 # 3 Testbed and equipment requests
18:45 # 4 Activity (and Sugar) testing moving upstream
18:45 tabitharoder We have only one thing on the list - developer request to test turtle art portfolio version 8
18:45 mchua 2 = "tools are annoying, we should fix them next round"
18:46 3 = we can talk about this after 8.2.1 along with 2
18:46 4 = it's happening, w00t; now upstream's problem
18:46 m_stone: I'm done :) your turn
18:46 m_stone tabitharoder: a small suggestion -- I've gotten a variety of ideas about things that people would like testing help with from reading the questions that people are asking in the http://wiki.laptop.org/go/Depl[…]ngs#Meeting_notes
18:47 so that might be worth perusing if you're looking for people to collaborate with.
18:47 so...
18:47 mchua tabitharoder: on the other hand, the welly testers are *really* great at Activity testing (which is shuffling upstream), and other than garycmartin nobody else is really doing that right now
18:47 m_stone something I've noticed over the last few months of life around olpc (note, for context, that I'm no longer employed by OLPC...)
18:48 is that there are a bunch of people using our laptops who really seem to like having Releases that they can plan their life around.
18:48 and I've also noticed that there are a bunch of people, present company included, who seem to derive real satisfaction from participating in the creation of those Releases.
18:48 tabitharoder I would like to see a monthly focus for testers and developers if possible
18:49 mchua m_stone: I'd actually say that the welly testers should take and own activity testing, perhaps keep an eye on activity compatibility for 8.2.1 for this round, but generally you folks around 1cc / australia are in a better place to do the wireless/ofw tests, thoughts?
18:49 tabitharoder hey this is what we developers are doing this month for you to test next month
18:49 m_stone (as opposed to the day-to-day grind of patch-level and package-level software evolution.)
18:49 tabitharoder hey this is what we found in testing can you fix over next month and get back to us for next test next month
18:49 m_stone tabitharoder: that's a helpful suggestion; thanks.
18:50 mchua m_stone, tabitharoder: it sounds like perhaps what we haven't yet set up - and might want to - is a qa cycle to parallel the release cycle
18:50 tabitharoder :-)
18:50 m_stone so... the basic thing that I'm wondering is: do we like making things -- releases I guess -- enough that we want to try to keep doing it?
18:50 mchua I'm a +1 for release cycle rockin'.
18:50 m_stone I'm asking in the context of a couple of other proposals that have been put forward recently for how this might unroll:
18:50 e.g.
18:51 mchua waits
18:51 m_stone a) people become satisfied with whatever Fedora happens to kick out
18:51 b) stasis ensues because nobody can muster the coordinated effort necessary to make new releases
18:52 I think those are the two other semi-credible proposals that I've heard floated.
18:53 so really, I'm curious about people's thoughts on what things they find satisfying about these several possible worlds...
18:53 and what they think the consumers of our work would find satisfying...
18:53 mchua I'd add two more
18:53 m_stone please.
18:53 mchua c) deployments start and drive their own release cycles, without a centralized release/testing group
18:53 tabitharoder I have recently started dancing classes and have been learning about the role of the leader and follower - any idea who they are in this case?
18:53 m_stone (and generally, "how you want all these things to go down")
18:53 mchua d) (the already-implicitly-stated) a volunteeer release team continues to make releases
18:54 tabitharoder: in the context of developers and testers?
18:54 tabitharoder and other
18:54 m_stone tabitharoder: that question sparks several ideas for me, but maybe you'd like to elaborate a bit more first?
18:54 mchua m_stone: of the ones listed, I'm in favor of (d), but I think you knew that already.
18:54 tabitharoder developers, testers and other
18:54 m_stone (or do you want me to react first?)
18:55 mchua I'm curious to hear m_stone's reaction, but would also love to hear kimquirk 's thoughts
18:55 notes that we're getting close to the supposed-to-be-an-hour-long meeting end time, but is willing to run over if people find this discussion valuable to continue.
18:55 kimquirk ...sorry, I was trying to start the 40 laptops... i'll catch up
18:56 m_stone kimquirk: I'm doing market research on people's commitment levels to various sorts of continued participation...
18:56 tabitharoder: nobody else seems to be talking, so I'll go ahead and offer you some reactions.
18:56 kimquirk personally, I may only be able to commit a small chunk of time around a release (like what we are doing today)
18:56 mchua kimquirk: and tabitha is asking whether the dancing concept of "leader and follower" applied to the relationship between developers and testers (and other groups that might be present)
18:57 m_stone (others should feel free to cut me off as soon as they have something to say)
18:57 so, here goes...
18:57 mchua I have reactions to both, but will go after m_stone
18:57 tabitharoder Ok, well WLG suggestion might look something like- there is a wiki page that developers and testers meet in - developers request their activity make the test hit list for the month and say what part of their activity to test (and version) - testers know what to focus on - they feedback to developers - loop returns and developers make changes and say what to test next month
18:57 may require a facilitator / QA person to map it
18:57 kimquirk mchua: tabitharoder - I think so... it is always good to have someone that is designated leader for a release (or a dance).
18:57 m_stone tabitharoder: for me, "leaders" and "followers" is most interesting when applied to the relations between consumers of software and the producers of software.
18:57 mchua tabitharoder: that sounds like activity testing upstream @ sugar labs to me. ;)
18:58 kimquirk that way others can feel like they can join in but don't have to do as much work...
18:58 mchua listens to m_stone
18:58 kimquirk m_stone: hmmm... I hadn't thought of it that way
18:58 m_stone so, from my perspective,  plan (b) "stasis" is what happens if we have no active leadership at all.
18:58 (most likely
18:58 )
18:58 tabitharoder loving this discussion
18:59 EKML m_stone: I'm thinking nothing
18:59 m_stone plan (a) "take what Fedora gives us; try to blend in a bit" seems...
18:59 well, suffice it to say that I don't feel much leadership pull from Fedora.
18:59 from my perspective, it's going to meander off in whatever direction its constituents like best.
18:59 kimquirk I agree... it will meander...
19:00 but a 'leader' requires a time committment
19:00 m_stone but I don't really get the sense, even after attending two FUDCONs, that Fedora has any particular software agenda that it wants to pursue.
19:00 tabitharoder: in a sense, I think that Fedora is dancing, but only for itself -- not really for the people who are using the software that /we've/ collectively made "with Fedora's help"
19:01 now, I could be totally wrong about that.
19:01 tabitharoder listening
19:01 kimquirk I think you are right
19:01 m_stone there are certainly several folks in the Fedora world who go somewhat out of their way to help us out.
19:01 tabitharoder and dying to ask question about where this meeting log can be found
19:01 m_stone tabitharoder: since you asked, I'll be happy to publish minutes just like I do for my other meetings.
19:01 would that be good?
19:02 (I'm not sure that I can do it forever, but I can certainly do it here.)
19:02 mchua m_stone: meetbot is logging as well
19:02 m_stone ah, okay.
19:02 perhaps that will suffice.
19:02 anyway, returning to my point-by-point analysis...
19:02 mchua tabitharoder: http://meeting.laptop.org/olpc[…]0090129_1803.html, for the record
19:03 tabitharoder thanks Mel
19:03 m_stone I think that option "c", (uncoordinated deployment hackery) is unlikely to end well.
19:03 in the foreseeable short term, anyway.
19:03 again, it's a situation where there's no clear-cut leader at present.
19:03 and where it's not at all obvious how to adjudicate competing demands.
19:03 i.e. how do the big deployments and the small deployments work together?
19:03 EKML m_stone: That kind of thing leads to a leadership by Ego - which is bad.
19:03 m_stone how does a primarily spanish-speaking deployment justify helping, say, the mongolian deployment?
19:04 I'm not really sure.
19:04 furthermore, while it's possible that someone in one of those deployments has an answer...
19:04 I know that I haven't read it yet if they do.
19:05 so that suggests that the necessary... "communication juices?" aren't really flowing.
19:05 tabitharoder well as a starting point we can kick it off somewhere on the wiki (maybe an existing page adaption rather than new page number 6billion) and a leader or seven may surface naturally?
19:05 m_stone tabitharoder: so getting down to the last point.
19:06 kim's right, I think, that the limiting factor there is time.
19:06 well, time, interest, commitment, etc.
19:06 tabitharoder it is true, time is everyones issue presently - especially since now nearly everyone is volunteer
19:06 m_stone afterall -- we /know/ how to make releases together.
19:07 we've done several of them and they've gotten substantially better as we went along.
19:07 tabitharoder so much more important to get communication clear and precise and timely when we are all time pressured
19:07 m_stone tabitharoder: maybe. or so much more important to understand the limitations that the other parties are working under and to accomodate expectations to fit.
19:07 *adjust
19:08 mchua still listening, but with several thoughts brewing
19:08 m_stone i.e. maybe we can't do as big a change as 8.2.0 in just six months. maybe that two or three tries spread over 12, or 16 months.
19:09 (or maybe we'll find out that volunteer releases with a team which has worked together in the past go quite smoothly and life is peachy!)? :)
19:09 tabitharoder for now, we will make the steps us as we go along, and when the tune changes be ready to follow?
19:09 m_stone tabitharoder: but the bottom line is that you want to keep dancing?
19:09 tabitharoder of course, my feet just cant keep still ;-)
19:09 m_stone and that you want a sensitive partner withwhom to enjoy the evening? :)
19:09 ah hah.
19:09 tabitharoder lol
19:10 mchua wonders how far this analogy is going...
19:10 tabitharoder The dancing group is expanding and I think Mel likes it enough to consider hanging around ???
19:10 m_stone feels satyr-like...
19:11 tabitharoder Well, with mind inspired I am ready to continue the day, with a few good ideas on what WLG testers can do tomorrow and what discussions to have over this week, thanks
19:11 m_stone tabitharoder: great, I'm glad you found the conversation inspiring.
19:11 mchua m_stone: so to summarize, are you proposing (d) as what you think is the best option, with more articulation on how testing fits into that cycle?
19:11 m_stone thanks for suggesting such a fine metaphor for analysis!
19:12 mchua: as I said -- I'm conducting basic "market research" to find out how much interest there is in each option.
19:12 mchua: I know that, at the moment, I'd love to have a credible excuse to try (d)
19:12 mchua as would I.
19:12 m_stone but it's not something that /I/ can pull off by myself. :)
19:13 (or that anyone can, I think)
19:13 tabitharoder offers supporting hand to any option
19:13 m_stone good to know; thanks.
19:13 mchua: you said you had some thoughts.
19:13 perhaps you'd like to offer them?
19:13 mchua m_stone: if you're done with yours for the time being, aye.
19:13 m_stone go for it.
19:13 mchua first, +1 to all of m_stone's responses.
19:14 I would love an excuse to try (d) as well.
19:15 I think a release cycle is a valuable thing for deployments, and since it seems like pretty much all the contributors are ultimately in it to support deployments, it's useful to contributors as well.
19:16 EKML Release cycles give people something to aim for
19:16 m_stone EKML: and we seem to /like/ building things together.
19:16 cjb hometime for me.  'night all!
19:16 EKML Yah
19:16 mchua for me, the part that's been missing (and that I haven't been able to identify a week or so ago,  or whenever m_stone started pulling people onto testing) has been the notion of where testing fits into the release cycle
19:16 EKML caio cjb
19:16 mchua night cjb!
19:16 cr_lf goes to lunch but notes for the record that an email was sent to Ian Thomson re the security requirements.
19:17 EKML gra
19:17 Lunch is a good idea.
19:17 mchua to use m_stone's producer/consumer analogy, the way I thought (and still think, right now) about QA in that context is as the first-in-line and very, very vocal consumer of the software that developers produce
19:18 (though if that's not a useful way to think about it, I'd love to hear others- this is my first naively formed view.)
19:18 and because of that, to use tabitharoder's analogy, I thought of testing as following the lead of development and the release cycle.
19:19 EKML ...sometimes
19:19 mchua for instance, edmcnierney, m_stone, kimquirk, and I had a conversation once (in patmos) that concluded with the agreement that ed (as release manager) would announce builds to test and publish a changelog of things to look at
19:20 kimquirk (taking a bit of a chocolate break... sorry)
19:20 mchua and that QA should wait for those things.
19:20 wants a chocolate break!
19:21 so I was sitting there for quite some time wondering when the lead was going to take a step, so to speak.
19:23 m_stone, I think you were able to pick up on this test cycle more readily than I was because you've driven the release cycle before and have an idea of the road ahead / where to keep an eye out for oncoming obstacles, whereas I was still waiting for something to pop out at me in the dark (after being told that things /would/ pop out at me in the dark.)
19:23 (for instance, recent thoughts have included things like "hm, a new staging build has been released. but nobody's told us to test it. hm, another one... man, when are they going to ask us to test staging?")
19:24 I think now that not prodding ed (and now cjb) on that given the recent chaos was an omission on my part.
19:26 EKML considers
19:26 mchua m_stone, cjb: as past or current release managers, how would you like testers to fit into the release cycle?
19:29 tabitharoder waits eagerly for the answers
19:29 EKML heh
19:29 bbiab, need food before implode
19:30 mchua my thoughts aren't as well-formed as m_stone's, but can mostly be summarized by "it seems like developers have something in the cycle to aim for, but testers who aren't developers are currently waiting for targets to pop out in front of them hollering to be shot. How can we change this?"
19:30 (That's all I have right now.)
19:31 tabitharoder what are they aiming for? can they communicate that to the right people?
19:31 oh, better go, we are about half an hour over time!
19:32 m_stone mchua: hello again.
19:32 returns from chocolate-delivery duties.
19:32 tabitharoder looking forward to meeting notes and continuuing this discussion later, bye
19:33 m_stone tabitharoder: bye!
19:34 mchua: I take it that you want me to say a few words? :)
19:34 mchua m_stone: I'll grab myself some chocolate while you read the backlog. :)
19:34 m_stone sure.
19:34 mchua m_stone: aye; there are two questions for you up there.
19:35 m_stone aa: hello!
19:35 mchua m_stone: and a third open question of "it seems that you have been a more effective test manager than I have been for this release; why {would I say this, might this be the case}?"
19:35 andresambrois / aa: greetings!
19:35 m_stone mchua: here are several thoughts; none particularly authoritative.
19:37 mchua returns from chocolate-finding
19:38 m_stone we can draw some insight into release management from the theory of concurrent communicating processes
19:38 notable features of CCPs are: "progress", "liveness", "deadlock", "starvation", "livelock", "MTBF", etc.
19:39 "contention", as well, I guess.
19:39 several notable features of release management not expressed by CCP theory include "motivation", "risk", and "uncertainty".
19:40 mchua: are these terms familiar or foreign?
19:40 mchua m_stone: some are; liveness, starvation, livelock, and MBTF aren't to me, but I'm wikipediaing right now.
19:41 (this is helpful, thanks.)
19:42 m_stone sorry, "mean time between failures"
19:42 MTBF.
19:42 mchua ah, okay. then MTBF I've heard, yes.
19:45 m_stone: finding these terms via google and wikipedia is turning out to be slow - could you keep going ahead with the CCP analogy, and I'll try to guess definitions by context and ask if I'm confused?
19:46 m_stone how about I offer some unofficial definitions?
19:46 so by "progress", I really mean "reason to believe that the process will eventually terminate"
19:46 mchua that works too :)
19:47 m_stone by "liveness", I mean "can I tell when a component [person/subtask] is alive?"
19:47 by "deadlock", I mean "when A is blocked on B and B is blocked on A" (and more general configurations)
19:48 by "livelock", I mean "when A and B are flipping from state to state to state in response to one another's messages but making no progress"    (and more general configurations)
19:48 i.e. "chasing each other in circles"
19:49 by "starvation", I mean that A needs some opaque resource in order to make progress -- frequently applicable when A is in "contention" for a scarce resource with B.
19:49 by "MTBF", I mean "mean time between failures"; that is, a measure of "how often do things break down?"
19:49 (such that they require fixing in order to resume making progress)
19:50 these are some sorts of descriptive ideas which are handy for analyzing and classifying various sorts of concurrent programs, including, I claim, the one /we're executing/ in order to make releases happen.
19:51 anyway, I bring it up because of your question about why things are moving more quickly now than they were last week, or the week before that, etc.
19:52 mchua m_stone: how would you describe the situation now (compared to say, 2 weeks ago) using those terms?
19:53 m_stone well, I think that we've had at least two instances of deadlock between Mitch and The World which needed to be broken before progress could be made on #9045.
19:53 The first was agreeing on a design.
19:53 then there was contention for Mitch's time from some windows testing.
19:53 once that was resolved, we had more deadlock over testing.
19:53 Mitch wanted people to test his code before making a release; others... weren't testing. for mysterious reasons.
19:54 I got the system unstuck from both instances of deadlock...
19:54 the first time, by writing up a proposal on the [[Partial key autonomy]] page which got some discussion going...
19:54 and the second, by stepping in to test Mitch's code.
19:55 (and to reassure him that it would /be/ tested as he made it.)
19:55 another example -- nobody was sending out mail saying: "please test staging-nnn."
19:56 I don't know why no-one was doing that -- I think anyone could have, and I tried to get bpepple to do it a couple of times.
19:56 but it wasn't happening.
19:56 so I sent some mail and, lo, some test results came back.
19:56 that seems... almost like a "clocking" issue.
19:57 (some circuits are much easier to build around a clock signal; others are easier to do async...)
19:57 what else?
19:57 holding a release status meeting... two weeks ago? helped.
19:57 it was a spontaneous sort of thing -- kimquirk just showed up on IRC...
19:58 but we did it, and I wrote a mail about it.
19:58 and that's when the test results started coming in.
19:59 so anyway, I don't think that there's really any magic here -- I just think that people seem to respond well to specific weekly requests and that nobody was making those weekly requests.
19:59 it might be valuable to examine the written record (i.e. email) in order to attempt to confirm or deny that hypothesis.
20:00 mchua m_stone: that matches up with my memory of events.
20:02 m_stone: I think on all of the things you mentioned - the two #9045 deadlocks, the "please test staging-nnn" emails, I was waiting for a clock signal from the release manager; you went and set one.
20:02 m_stone mchua: in short -- clock signals show up all over the place in life -- in daily and weekly rhythms, in dances, in circuits, ...
20:02 and the people who have to do the work to make releases go for olpc seem to be clocked at weekly tempos.
20:02 so, while you can get /some/ things done without supplying that tocsin, it's hard to build any momentum.
20:03 (in other words, I admire Ed's faith that people can work without being micromanaged, but my experience and experiments with this particular group of people seem to contradict some of his imperatives.)
20:04 has more blog posts to write now...
20:05 mchua: critique?
20:06 mchua m_stone: would you like to continue setting that clock cycle for the remainder of the 8.2.1 cycle?
20:06 m_stone mchua: is anyone else going to if I don't?
20:07 mchua: (the short answer is "yes!... but I need to find a job...") :)
20:07 mchua m_stone: do you have other things that are more pressing to do? you certainly seem to be in a better position to do it for at least the next week or two than I am.
20:07 m_stone: (...agh, don't remind me of that!)
20:07 m_stone mchua: I can probably keep it up for the next week or two.
20:07 (which, I hope, is all that it will take for 8.2.1)
20:08 but, as I hinted at today, the /interesting/ question is what comes after 8.2.1...
20:08 staging-25, in my opinion, is probably good enough for anyone who really /needs/ 8.2.1...
20:08 mchua m_stone: I can follow behind and document, handle release notes, and work on moving testing upstream, which is what I've been spending most of my energies on.
20:08 m_stone and who can stand the uncertainty of it not having been /fully/ QA'ed.
20:08 help with relnotes would be great; I suck at those.
20:09 I'm a bit less convinced by this "moving testing upstream" buness though... :)
20:09 mchua m_stone: I can be a documentation ninja, but without visibility into the development side of the release process, I'm a pretty lousy clk.
20:09 m_stone mchua: well, what visibility is missing?
20:10 mchua m_stone: can you elaborate on the upstream thing while I'm typing up an answer to that? :)
20:10 m_stone mchua: it's the "upstream" part that makes no sense to me.
20:11 what do "streams" have to do with testing?
20:11 mchua m_stone: activities and sugar-core?
20:11 m_stone there's just testing. some of it is unit, some functional, some integration, and some process-based.
20:12 what matters is that it's done in appropriate measure, to sufficient quality, and that it provides sufficient satisfaction, support, and opportunity to grow to the participants.
20:12 who cares what name it's done under?
20:12 mchua m_stone: the name it's done under isn't important, but disseminating the results to those who need them and trying to reduce redundancy of testing are important.
20:13 m_stone do you have any examples where these things have been problematic?
20:14 mchua: if not, then don't overengineer. just test more stuff more extensively with more people.
20:15 kimquirk good talking to you all... i gotta run
20:15 m_stone kimquirk: it was a pleasure as always; thanks so much for coming in!
20:15 kimquirk i'll look for 'test events' on the testing mail list
20:15 mchua m_stone: "I'm trying to run sugar on $some-other-operating-system and can't get activity X to run, is it broken?"
20:15 kimquirk m_stone: thanks for the chocolate!
20:15 m_stone sure. let's plan on having something again in a couple of weeks?
20:15 mchua waves to kimquirk
20:16 m_stone mchua: what's the problem there?
20:16 kimquirk i'll write up an email about this test setup so cjb and dogi or adam can check its progress tomorrow
20:16 m_stone kimquirk: great; thanks!
20:16 mchua m_stone: "I'm packaging sugar for $distro, what's the status of the various components I may be wrapping up?"
20:17 m_stone: basically, that sugar and activities no longer have olpc as their sole consumer
20:17 m_stone mchua: yeah, but what does that have to do with anything?
20:18 mchua: (also, how many people does that actually matter for? five?)
20:18 mchua m_stone: that the notion of streams is useful for dividing testing labor/attention.
20:19 m_stone mchua: that's not a complete sentence; please complete it so that I can understand it.
20:20 mchua working on it...
20:22 m_stone: The notion of "streams" is relevant to testing of a product composed of multiple disparate components because it helps (1) divide the task of testing that product into more manageable subcomponents that are easier to tackle, and (2) facilitates the spread of test results from each component to other products that may be using the same component.
20:22 m_stone: how's that?
20:22 m_stone mchua: seems bogus, but maybe I didn't understand it. could you flesh it out a bit more, e.g., with an example?
20:23 mchua was in the middle of typing one
20:23 m_stone well, "bogus" might be too strong.
20:23 mchua doesn't mind bluntness
20:23 m_stone the frist claim  is plausible but exceptionally weak since it offers no guidance about how to make useful divisions.
20:24 the second claim seems false -- why do streams have anything to do with helping to propagate component-level test information?
20:24 mchua ok, I'll do an example first and then I'll address each claim in turn.
20:25 welly testers meet tomorrow; we have limited amounts of equipment and time.
20:25 I am pretty positive that "test 8.2.1" is beyond our capabilities to finish (also, we don't have the testbed/equipment to do some of the large-scale testing, etc.)
20:26 therefore it makes sense to define a limited subset of things to tackle tomorrow morning that can be finished and reported by that group in that amount of time.
20:26 m_stone sure...
20:26 mchua one such subset could be "test Activity compatibility with 8.2.1," since that seems to be an issue given garycmartin's earlier explorations.
20:27 let's say we spend the morning doing that, and end up testing g1g1 activities against 8.2.1, it all goes well, we have results, hurrah.
20:27 where should those go?
20:28 to the 8.2.1 release team, certainly, as we think it's important that those Activities work with 8.2.1 when it's released.
20:28 but who else might those results be useful to? the maintainers of those Activities, for sure.
20:29 Possibly the sugar-core developers, if some incompatibility is due to changes in sugar-core.
20:29 m_stone indeed, all fine thoughts.
20:29 mchua I'll set aside the people packaging activities for sugar on other distributions for now, as you've pointed out that this is a small group at the moment (and none of the are vital to deployments, as I know.)
20:29 m_stone also to other testers, who might be motivated by your example
20:29 mchua Right.
20:30 Where do those people work, and what do they consider themselves to work on?
20:30 m_stone don't you think that sugar-devel@, devel@, testing@, and /maybe/ fedora-olpc@ and debian-sugar@ would cover it?
20:30 mchua The 8.2.1 release team is working on the 8.2.1 release; OLPC community testers are working on testing OLPC releases. devel and testing and the OLPC wiki page, plus individual pings on IRC and email as needed, would suffice.
20:31 for announcements, yes.
20:31 m_stone then let google handle the rest, no?
20:31 mchua but I would like for announcements of test results on mailing lists to be of the form "check out the test results we've reported here"
20:31 rather than "check out these test results <MASSIVE DUMP INLINE>"
20:31 m_stone mchua: and...?
20:31 still hasn't seen the problem...
20:32 mchua m_stone: test case management systems are useful for long-term aggregation and statistical analysis of test results
20:32 m_stone mchua: perhaps; they're also a pain in the ass.
20:32 mchua m_stone: why do we use trac instead of shouting bugs out on the devel mailing list (and perhaps keeping individual running notes on random wikipages?)
20:32 m_stone mchua: probably because Ivan thought it was a good idea two years ago.
20:33 and once we started, it wasn't really worth changing.
20:33 mchua m_stone: our current test case management system is indeed a PITA, but it doesn't mean that test case management itself is a bad idea.
20:33 m_stone mchua: of course not.
20:33 mchua: anyway, I think you're arguing more about test /result/ management than test /case/ management.
20:34 mchua m_stone: it also gives us the ability to do things like queries by component, track the status of bugs as they flow through a cycle, see how far we've progressed towards a milestone, ec.
20:34 s/ec/etc
20:34 m_stone mchua: does anyone use that?
20:34 mchua m_stone: test results are usually handled by test case management systems, I believe.
20:34 m_stone is pretty sure that some simple tagging would work just as well...
20:35 mchua m_stone: simple tagging of what? mailing list emails? wiki pages?
20:35 m_stone I was thinking of wiki pages.
20:36 mchua: don't get me wrong -- I have nothing against TCM when judiciously applied. I see plenty of benefits to having it around.
20:36 it certainly helped to coalesce a fledgling systematic testing effort for 8.2.0 which is paying off, e.g., today.
20:36 I'm just not sure that the mechanical details of the system matter so much.
20:37 mchua the implementation details of the system don't matter; the existence (and usage) of /some/ system does.
20:37 otherwise you end up with concurrent processes that don't know how to listen to each other.
20:37 m_stone mchua: not as much as the simple desire to perform systematic testing.
20:38 mchua: maybe; I'm unconvinced.
20:38 mchua that desire will usually create some sort of system to perform said systematic testing.
20:38 m_stone so am I right, though, that the "streams" idea you were discussing before was really about "what sort of TCM system could I use/build in order to better organize this big, distributed, multi-level, funky test effort"?
20:38 mchua m_stone: anyway, your original question was as to whether the notion of streams was relevant to testing.
20:38 m_stone :)
20:40 mchua m_stone: perhaps it's better rephrased as "how can we ensure that the QA needs of multiple groups are being met, not just the 8.2.1 release team?" and the notion of streams seemed like a useful one to investigate.
20:41 m_stone mchua: (fyi, a better tcm from my standpoint would probably consist of a git repo with some directories for products, some directories for results, some directories for subsystems, and some dirs for test cases. then insert symlinks as needed until ls and grep can produce all the necessary statistics.)
20:41 (but I'm strange.) :)
20:43 mchua m_stone: also, keep in mind that "is it of high enough quality?" means "does it satisfy the customer?" which implies interfaces and output formats for non-speakers of engineeringese.
20:44 m_stone mchua: ah, but I tend to see the Person who Writes the Release Notes as that interface.
20:44 anybody else just needs to learn engineeringese.
20:44 or hire an interpreter.
20:45 mchua m_stone: I disagree.
20:46 m_stone: that may work fine for internal engineering features that aren't exposed to endusers, because in those cases the developers are the endusers.
20:47 m_stone: but if we want to see whether a feature implementation works for an enduser that isn't an engineer, we have to check that *before* we say "it's done! and we've released!"
20:47 m_stone mchua: no, not at all.
20:47 in fact, quite to the contrary.
20:47 you should check /after/ you've released it.
20:47 releasing it just means that you think it /might/ be good enough.
20:48 I agree that you should educate people about this fact -- that "released" and "proven useful" are entirely different beasts.
20:49 but I see that "relevance" testing as being a substantially higher level, /non-iterative/ (i.e. recursive) form of QA.
20:49 which I haven't the faintest clue how to begin systematizing.
20:49 (maybe you do, in which case you case you are certainly my superior in this matter)
20:50 mchua m_stone: I tend to take a very user-facing view of things, as you've probably noticed by now.
20:51 m_stone mchua: it's hard for me to say. I'm not sure I've ever heard you ask "well, does this do the /right/ thing?"
20:51 for the people I tend to consider end-users.
20:51 (I've definitely heard you ask it for people I consider producers, like, e.g. tabitha)
20:52 and me, for that matter.
20:53 mchua m_stone: well, the easy answer to why you may not have heard me ask that is that you're not a non-technical end user. :)
20:54 You're an engineer; I interface with you as an engineer.
20:55 m_stone mchua: fair enough. do you not converse with end-users in public?
20:55 did I just miss it?
20:56 (the latter is entirely believable -- I miss lots of stuff)
20:56 mchua m_stone: end-users tend to not start out by using engineering communication channels, so...
20:57 m_stone: one ongoing task is the translation and forwarding of enduser results to places where they're visible to the relevant developers (as in http://lists.laptop.org/piperm[…]ember/000585.html, which is partially translated and pushed-out.)
20:58 m_stone what am I looking for in that mail?
20:58 (or in its surrounding context?)
21:00 mchua m_stone: imagine getting a teacher or a student, with no exposure to software engineering or even the notion of a bug, to even write something like that.
21:00 m_stone mchua: I have. remember when I answered that question at sugarcamp:
21:00 by saying that you ought to act as though you were writing a newspaper article?
21:00 mchua (I wasn't at all the sugarcamp sessions, so I might have missed that one as well.)
21:01 m_stone answering the who, where, when, why, what, how, etc. of the occurence?
21:01 I think I was explaining it to John Tierney.
21:01 mchua sure, but you had to tell him that, right? he didn't just walk in magically knowing that that was a useful way to think about it.
21:01 m_stone your point?
21:02 (incidentally, let me know if I'm pushing you too hard. it's sometimes hard to tell over IRC)
21:02 mchua (no worries, I appreciate the questioning.)
21:04 my point is that you seem to expect a majority (nontechnical endusers) to use the language of an elite minority (engineers) in order to participate in a process that's ostensibly designed to serve and be responsive to them.
21:05 m_stone ponders
21:05 mchua my much earlier point, which is more relevant to 8.2.1 testing, is that you're better at driving the engineering-facing side of 8.2.1 testing than I am, and that if you'd like to continue formally in that capacity I'd rather welcome it. :)
21:05 m_stone mchua: is there a good analogy to medicine lurking here?
21:05 mchua m_stone: perhaps, but none immediately come to mind.
21:06 m_stone huh. it seems like a classic example of jargon used by elite minorities interfering with participation in processes ostensibly designed to serve end-users.
21:06 (and tools, procedures, authority relationships, ...)
21:07 mchua well, I don't go to my doctor and say "lets start with some bloodwork.  Collect and send for clotting studies, PT, PTT, factor 5, protein, CNS..."
21:07 m_stone accounting is probably another fine example.
21:07 you don't? :)
21:07 mchua I usually start out with something like "I cut my leg, and it hasn't stopped bleeding in the last half-hour, and I think I'm going to faint now."
21:08 m_stone okay, but what does this have to do with choice of TCM?
21:10 mchua oh, nothing.
21:10 (I also have to run to meet cr_lf soon, so would like to wrap up this convo shortly.)
21:10 m_stone okay.
21:10 until next time!
21:11 mchua I was pointing out our different foci on testing; you're further down the engineering spectrum than I am, I consider myself a bridge to endusers, that gives us different values and perspectives at times.
21:12 m_stone: to wrap up - you'll drive the clock cycle for the rest of 8.2.1 testing?
21:12 m_stone: which, as I see it, means "keeping development unstuck / without QA as a bottleneck to their release work"?
21:14 m_stone: I'll do release notes, enumeration and tracking of the needs you state that development has from QA, and get people to run the test cases you articulate.
21:15 m_stone mchua: we'll see how it goes.
21:15 but yes, that's the general plan.
21:15 mchua m_stone: (in other words, you drive the "hey guys, please test X" mailing list announcements (and the Friends in Testing page, with bpepple), I'll watch the list for your announcements and people's notes, and prod results and tracking into solidity on wiki pages.)
21:16 m_stone mchua: I also strongly encourage you to do what you can to organize testing that you think would be useful to the folks showing up in the deployment mtgs.
21:16 mchua: fine, fine, but no need to be so official about it.
21:16 :)
21:16 just poke me if you're feeling blocked on something.
21:16 and, if you're lucky, I'll unstick you.
21:16 (or find someone else to do so.)
21:17 likewise if you /see/ problems elsewhere.
21:17 mchua m_stone: I don't think I have bandwidth to watch deployment meetings for at least another week.
21:18 m_stone: right now, getting today's test results from 1cc out to the testing ml should be all I need; this month's testing ml archives + the current 8.2.1 test cases page will be what I work from for starters.
21:18 I expect to hit confusion/blockers while writing those up into release notes, and will holler when I do.
21:19 I've got to run now; thanks for getting 8.2.1 QA unstuck.
21:19 (If you'd like to make an announcement to the testing list of the "michael == clk" arrangement, go for it. I'll shoot out logs now.)
21:19 #endmeeting

Index | Today     Channels | Search | Join

Powered by ilbot/Modified.