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

#sugar-meeting, 2009-01-22

Index | Today     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
09:21 tomeu gregdek: erikos has been thinking about bug triaging, we can reserve that point for when he joins us
09:22 gregdek ok.
09:22 It's pretty critical.
09:22 a) February the 13th is the due date for our Sucrose 0.83 Release Candidate 1 (DevelopmentTeam/Release/Roadmap#Schedule). What needs to happen in the next weeks to get there?
09:22 erikos oups sorry - i am late :(
09:23 gregdek Yay!  :)
09:23 Hi erikos!
09:23 garycmartin erikos: hi!
09:23 gregdek So.
09:23 Step 1: Figure out what the bugs are.  ;)
09:23 But I suspect we need more detail in that statemet.
09:23 statement.
09:25 erikos: It is said that you have some ideas on triaging.  Care to elaborate?
09:25 erikos gregdek: i have written up a triage guide one sec - let me find the url
09:25 gregdek: http://sugarlabs.org/go/BugSquad/TriageGuide
09:26 gregdek: so - on my list are some trac changes needed for that
09:26 gregdek: i did ping coderanger weeks ago - but had no luck
09:26 gregdek looks.
09:27 erikos gregdek: pinged mstone today - since he did something similar to the oplc trac instance
09:27 gregdek All right.  My take:
09:27 In a small project, developers sometimes have to double as QA folks.
09:28 erikos agreed
09:28 gregdek I wonder if it might not be worthwhile for everyone to spend the next week doing nothing but triage.
09:28 I know a week is expensive.
09:28 But not having real visibility into actual problems is more expensive.
09:28 Does that sounds sane, or insane?
09:29 erikos i agree - with that so i think two items i have to hammer out: go over the triage policy
09:29 add the pieces missing to trac
09:29 gregdek: so this would be two action items for me
09:29 tomeu gregdek: you mean triaging d.l.o?
09:30 erikos tomeu: personally i would not do that
09:30 garycmartin So if we re-find a bug do we move it from olpc trac to sl trac?
09:30 erikos garycmartin: yes if it is an upstream bug
09:30 tomeu because we don't have many bugs at d.s.o
09:30 gregdek Right.
09:31 So the process is probably:
09:31 (guessing)
09:31 1. Look at a laptop.org bug;
09:31 2. If it's not relevant, close it;
09:31 3. If it is relevant, tag it "upstream" and create a new sl.o bug;
09:31 (which seems like a lot of work, btw.)
09:32 Do we have a way of auto-submitting bugs from laptop.o to sl.o?
09:32 erikos gregdek: there should be a way of importing bugs into trac
09:33 tomeu gregdek: wonder if wouldn't be better to invest that time in testing sugar?
09:33 erikos tomeu: yeah, actually i feel a bit similar
09:34 gregdek If, and only if, we feel like the real-world tests of older versions of Sugar are mostly out-of-date.
09:34 But here's my opinion:
09:34 Everyone who filed a bug is a potential community member.
09:34 morgs is here very briefly
09:34 gregdek When someone files a bug, and no one *ever* responds to the bug, you lose them.
09:35 tomeu gregdek: the problem is that the bugs in d.l.o didn't came from the deployments
09:35 gregdek I would guess that there are at least a few good bugs that were filed by people who actually cared about the project enough to file a bug, and we have a chance to capture those people.
09:35 tomeu: why is that necessarily a problem?
09:35 They're probably still bugs, right?
09:35 tomeu gregdek: probably, but will be quite expensive to find the ones that are still bugs
09:36 gregdek Yes, it could be.
09:36 tomeu and those bugs were found by the same method of testing that we could do
09:36 gregdek The question is: do you leave the bug reporters behind?
09:36 And what's the cost of that?
09:36 tomeu I see, that's a very hard question ;)
09:36 gregdek :)
09:36 It's a community question.
09:37 erikos gregdek: i think - if we would go down the road - to care about the reporters
09:37 gregdek And it's a hard fucking problem, because triage is boring and really time-consuming.
09:37 Which is why I say:
09:37 erikos we would need to announce that triaging - so that we get as many people that reported bugs to pay attention
09:37 gregdek let's take a week -- no more -- to do triage.
09:37 erikos and follow up on it
09:37 gregdek And yes, *announce* that we're doing triage.
09:37 Loudly and proudly.
09:37 And be on #sugar talking about it.
09:38 tomeu ok, let me find a query on d.l.o
09:38 gregdek What do we need to do to make it easy to triage?
09:38 erikos is this the marketing meeting?
09:38 :)
09:38 gregdek LOL
09:38 When you're trying to recruit, every meeting is a marketing meeting.  ;)
09:38 erikos gregdek: i think the important part is the policy you have set up
09:39 gregdek: and the tools to be ready
09:39 gregdek How easy can we make it to "click a button and send this bug from laptop.org to sugarlabs.org"?
09:39 garycmartin gregdek: is 'triage' re-testing, or is it just looking through old bugs and deciding how to move forward on it?
09:39 gregdek garycmartin: It's probably a combination, and requires a bit of judgment.
09:40 garycmartin: Some bugs are obviously not helpful, and we should close them as politely as we can.
09:40 garycmartin: Some bugs are obviously relevant, and we need to see if we can duplicate them.
09:41 The first goal of triage is to find the gaping chest wounds.  :)
09:41 erikos gregdek: it would be good to have a testing environemnt ready for that as well - to judge the duplicates
09:41 gregdek erikos: Should we be asking testers to be running a particular jhbuild?  Should we be testing against head?
09:42 erikos gregdek: i think if we get SoaS running with latest 0.83.4 release we are fine
09:42 gregdek: marco started on that task
09:42 gregdek: we will meet later to have another look
09:43 gregdek Great.
09:44 So.
09:44 erikos gregdek: i fear a bit the time it takes to set jhbuild up
09:44 gregdek erikos: Fair enough.
09:44 erikos gregdek: and the investment in SoaS is needed in other places as well
09:44 gregdek I got lucky -- mine set up in a couple of hours.  Past experience tells me that was an anomaly.  ;)
09:44 (jhbuild, imean)
09:44 garycmartin FWIW: I can only test on XO joyride.
09:44 erikos gregdek: it works fine for me on fedora as well :)
09:45 garycmartin: and SoaS or?
09:45 garycmartin Nope
09:45 gregdek still hrms about the "moving bugs from laptop.org to sl.org" problem...
09:45 erikos garycmartin: you can not boot from the usb stick on another machine?
09:45 garycmartin I have no Intel machine. All Mac (ppc) here except for 3 XOs.
09:46 gregdek I'm afraid that will prove to be really painful for triagers, and confusing to the people who submitted the bug.
09:46 erikos garycmartin: ah, ok - well marco is working on getting it to run on the xo as well
09:46 tomeu garycmartin, erikos: but soas should also boot on a XO, right?
09:46 erikos tomeu: right
09:47 tomeu: i guess it will probably just take a bit longer to get there
09:47 tomeu ok
09:47 gregdek: first try at a query for sugar bugs in d.l.o: http://dev.laptop.org/query?st[…]umentation&compon
09:47 1085 aren't so much
09:47 so many
09:47 garycmartin SoaS boot on an XO, oohhh news to me. Well that's another option then for folks who don't want to risk a working XO.
09:48 gregdek 1000 isn't that bad!
09:48 goes to look.
09:48 erikos garycmartin: 'SoaS on the XO progress' is the tread on sugar-devel
09:49 gregdek Should we also filter out "assigned" bugs?
09:49 Since presumably "assigned" means "someone looked at this once and determined it to be relevant"?
09:49 erikos gregdek: hmmm, could be already fixed as well
09:49 gregdek Yeah...
09:49 It's kind of a two-step process.
09:50 Step 1 is corralling all the "new" bugs.
09:50 And turning them into "accepted" or "closed".
09:50 Then Step 2 is assessing all the bugs we've accepted and figuring out which ones are most important to fix.
09:50 tomeu: modify to see only "new" bugs?
09:51 And maybe even filter out "enhancements"?
09:51 erikos filter out for the first round?
09:51 tomeu ok, one sec
09:51 erikos but still worth to move that information over, right?
09:52 (if we still care of course)
09:52 tomeu gregdek: we didn't used the accepted flag
09:53 http://dev.laptop.org/query?st[…]gn&component=netw
09:53 added some more modules
09:53 gregdek Still 1086.
09:53 Only one different?  :)
09:53 erikos hehe
09:54 tomeu I get 1260
09:54 of those, 291 are enhancements
09:55 erikos hi cjb
09:55 cjb hihi
09:55 erikos i think we should answer the general question, if we think it is worth doing the efforts
09:55 tomeu benzea has done trac migrations in the past and has offered to help
09:56 but he needs to get a db dump
09:56 erikos 1086 or 1260 does not make a big diff
09:56 tomeu hi cjb, trying to figure out what to do with the wealth of bugs at dev.l.o
09:56 gregdek thinks.
09:56 Well...
09:56 ...ok, so here's my thinking now.
09:57 Moving bugs from laptop.org to sugarlabs.org one at a time will be very expensive.
09:57 tomeu cjb: isn't there some way of programatically accessing trac from the web?
09:57 cjb xml-rpc interface
09:57 gregdek Which means we can either:
09:57 cjb m_stone has a few python scripts that use it
09:57 gregdek 1. Make people move the bugs by hand as they see fit;
09:58 2. Provide a hook in the GUI to help;
09:58 tomeu so we may do a small python script that fetches a bug in d.l.o and adds it to d.s.o
09:58 gregdek 3. Mass import all Sugar bugs to sl.o immediately and tag the bugs on laptop.org as "upstream" with links to the new bugs.
09:58 Is 3. the best option?
09:59 erikos does not like 3
09:59 tomeu what if: have one sugar dev to go through all the bugs in dlo and mark those who things that _may_ be interesting
09:59 erikos gregdek: if the bug is olpc specific we have to move it back again
09:59 tomeu move all those tickets to d.s.o
10:00 then triage in d.s.o
10:00 people can start triaging in d.s.o before the first guy has finished
10:00 gregdek tomeu: Not bad.
10:00 erikos tomeu: you mean the bugs assigned to that person?
10:00 tomeu the first guy needs to know very clear if a bug could interest upstream or not
10:01 erikos tomeu: or all the sugar bugs
10:01 tomeu erikos: no, all bugs in sugar components
10:01 gregdek Puts a heavy load on that guy, but if there's a quick way to say "yes, yes, no, no, maybe, yes, no" it could be okay.
10:01 tomeu gregdek: that's the idea
10:01 gregdek nods.
10:01 tomeu gregdek: basically going through the report, and noting the bugs to move in a text file that can be feed to a python script
10:01 erikos i don't think this is an easy task for that guy :/
10:01 gregdek Which means a tool, since currently there's no good way to do that, is there?
10:02 tomeu erikos: it doesn't need to be a perfect job
10:02 gregdek Right.
10:02 Still not easy, though.  ;)
10:02 tomeu erikos: bugs moved to d.s.o will be triaged as any other new bug
10:02 erikos tomeu: i think we can do a good job if we meet for one day
10:02 tomeu erikos: that's going to be very slow :/
10:03 erikos tomeu: well - we can do simultanesly
10:03 tomeu tracs and bugzillas are thought so people can collaborate around bugs
10:03 let's use those tools
10:03 erikos tomeu: but be around to discuss the hard ones
10:03 tomeu erikos: what's the difference between an imported bug and a new one?
10:03 we are already doing the triaging work through trac
10:04 erikos tomeu: the imported one could be olpc specific
10:04 tomeu: more likely actually
10:04 gregdek So let that be part of the criteria.
10:04 tomeu erikos: there are new bugs in d.s.o that are olpc specific
10:04 erikos tomeu: sure, i mean more likely
10:04 tomeu erikos: we are going to have to deal with thos eanyway
10:05 gregdek Well, actually, that's an interesting question.  How do we know without digging into those particular bugs whether they are XO-specific or not?
10:05 erikos tomeu: you mean, this is a good exercise? ;p
10:05 gregdek And if they are, how do we deal with them?
10:05 tomeu gregdek: that's why we need an experienced sugar developer to do that
10:05 gregdek nods.
10:05 erikos tomeu: and who is that?
10:05 tomeu and I think it should be only one because having to work together will slow down things
10:05 erikos: you or me
10:05 or marco if he can find the time
10:06 erikos tomeu: well i fear marco has to go to the dentist again after doing that task ;p
10:06 tomeu yeah, it's a sugar-intensive task ;)
10:07 erikos tomeu: we might do this: you take d.l.o and i d.s.o and directly make sure the new incoming ones are triaged right in d.s.o terms
10:07 tomeu I don't think it should take many hours for the first guy to go through all the open bugs
10:08 erikos: but triaging in d.s.o will take much more time
10:08 I tihnk several people should deal with those
10:08 erikos tomeu: oh yeah but someone needs to coordinat them
10:09 tomeu erikos: we can split by component
10:09 erikos tomeu: at least at the start
10:09 ok we can figure out the details later i guess
10:09 do we agree on the general approach?
10:10 tomeu erikos: we need to see how we can do such a tool
10:10 erikos tomeu: the python script?
10:11 gregdek Well, if you're just picking trac ids to move over, you could just keep a commented list in gobby for that.
10:12 Once you've got a list of bugs, I imagine the import script is not too hard.
10:12 tomeu gregdek: yeah, I just hope that if several people work together, they don't decide to comment each bug
10:12 gregdek We'll have to resist that urge.  ;)
10:13 Splitting by component to start sounds sensible.
10:13 tomeu gregdek: if we could go sending the tickets as the list is consumed, the others in d.s.o could triage as usual
10:13 erikos agreed
10:13 tomeu ok, so erikos and me could go through the list at first them
10:13 gregdek "sending tickets" == "filing new tickets in sl.o trac"?
10:13 tomeu then
10:13 gregdek: yeah
10:14 gregdek Again, if the process is *trivial*, that's ok.
10:14 But if the process is not literally *trivial*, you will become bogged down and full of hate because of mind-numbing ticket shoveling.
10:14 That's my guess, anyway.
10:14 tomeu gregdek: which process is that?
10:15 gregdek Moving a ticket from one trac to the other.
10:15 Again: are we talking about a mass import after we've looked at tickets, or are we talking about moving them one by one?
10:16 tomeu I think the hard part should happen once the tickets get to d.s.o and could be done by the normal triaging ways
10:16 by a team of people
10:16 gregdek: I would move them in batches of 100 or so
10:16 gregdek That's a good idea.
10:16 I guess you'll kind of get a feel when it's time to move a new batch over.
10:17 All right.
10:17 erikos tomeu: sounds good to me as well
10:17 gregdek So the approach, so I understand and can communicate, is:
10:17 1. Experienced Sugar developers will move over bugs from laptop.org to sugarlabs.org that they think are still relevant.  VERY high level triage.
10:18 2. We will then focus on getting as many hands as we can to go through the sl.o trac to do more traditional triage, using SoaS as the benchmark.
10:18 Is that correct?
10:18 erikos correct to me
10:18 gregdek tomeu: Do I have it right?
10:18 erikos gregdek: we should note - that we need to figure out exactly how technically import the bugs
10:18 tomeu that's right
10:19 gregdek erikos: I think between you, tomeu and simon, you can figure that out.
10:19 But should we note it on the developer TODO?
10:19 tomeu oh, we are three now ;)
10:19 erikos gregdek: damn - looks like i have double work to do ;p
10:19 tomeu gregdek: guess so
10:19 gregdek Doh, heh.
10:19 LOL
10:19 s/simon/marco
10:19 tomeu I see a problem with leaving the tickets in d.l.o untouched
10:20 gregdek tomeu: Whatever import process you use will need to leave a note: "now tracked at sl.o, ticket # foo."
10:20 tomeu perhaps the script can also close it there?
10:20 gregdek OK, so, action items.
10:21 1. Script to move bugs from trac.sugarlabs.org to trac.sl.o.
10:21 Idiot.
10:21 erikos tomeu: yeah, there should be a note and they should be closed - or both
10:21 gregdek 1. Script to move bugs from trac.laptop.org to trac.sl.o.
10:21 erikos: I'd say both.
10:21 2. High-level developer triage.
10:21 tomeu ok, triagers can open it again if it turns out to be l.o
10:22 gregdek Yep.
10:22 3. Triage announcement and recruitment.
10:22 erikos tomeu: yeah, if ever someone will touch that database again
10:24 gregdek All right.
10:24 So, um, I guess we have marching orders...?
10:24 tomeu think so, yeah
10:25 gregdek Who's taking the lead on the import tool?
10:25 tomeu gregdek: we need to coordinate with cjb
10:26 gregdek Yes, we should.
10:26 cjb?  You around?
10:26 tomeu well, with edmcnierney_away
10:26 gregdek hrms.
10:26 cjb yes, definitely talk to Ed
10:26 Michael knows the xml-rpc interface and I don't
10:26 so him too
10:27 gregdek Let's get started.  The only thing we really need to coordinate is the final status of the laptop.org bug.  Do you want it closed?  Linked?  Left completely alone?  That's Ed's call.
10:28 So in parallel, we can start creating the list of Bugs To Be Moved.
10:28 Is that wiki?  gobby?  what?
10:29 tomeu not sure
10:30 perhaps wiki
10:30 we can get one thirs of the tickets each developer
10:30 go through them and build three lists
10:31 and each developer run the script every batch of 50 or something
10:32 gregdek Just need a way to get started and a place to put bug ids.
10:33 tomeu ok, let's add it on the todo list and move discussion to the ml?
10:34 erikos wiki is fine with me as well as tool
10:35 gregdek Got it.
10:35 erikos gregdek: you talk to ed?
10:35 gregdek http://sugarlabs.org/go/Develo[…]ntTeam/BugShuffle
10:35 erikos: I will talk to Ed.
10:36 erikos gregdek: thanks
10:36 gregdek Well, that's 90 minutes of our lives.  Shall we discuss more stuff, or shall we get back to it?  :)
10:37 erikos yeah, i hoped with you in the meeting we would get shorter ;p
10:37 tomeu depend, have we gone through the agenda? ;)
10:37 erikos tomeu: nope, not at all
10:37 gregdek: so i did update the todo list to my best knowledge before the meeting
10:38 gregdek: so we might not need to do this now
10:38 gregdek LOL
10:38 Sorry, guys.
10:38 Sometimes the meetings get shorter, sometimes longer.  I'll try to do better.  ;)
10:38 I guess we should at least touch on the other agenda items.
10:38 erikos gregdek: we are happy to have you around!
10:39 ok with me
10:39 gregdek b) Update DevelopmentTeam/TODO list
10:39 So, um, go do that, everybody.  :)
10:39 Maybe next week we walk through the whole list and get status on each item.
10:39 c) Auto-authentication for Browse when visiting web-based tools on the XS it has registered to (guest speaker Martin Langhoff)
10:39 Didn't see Martin at all today...
10:40 erikos nope, he might have forgotten :/
10:40 gregdek Sigh.
10:40 Anything to be usefully discussed in his absence?
10:40 Sounds like a new feature anyway...
10:40 erikos it is a feature, yes
10:41 gregdek And we're in feature freeze, yes?
10:41 tomeu though in an activity, so would be feasible to do a bundle for those deployments that need it
10:41 not as part of sugar, though
10:41 erikos if it would be only in browse - we could take it
10:41 tomeu: right
10:41 gregdek nods.
10:41 Shall we ping him for next week?
10:42 erikos sure, and note, that we talk on devel if he wants to discuss before then
10:42 gregdek http://sugarlabs.org/go/Develo[…]ntTeam/BugShuffle, btw, if you need it :)
10:42 OK.
10:42 erikos i will tell him
10:44 gregdek d) What about the activity updater?
10:44 What indeed?
10:45 tomeu well...
10:45 erikos If we do it, i think we should write it from scratch
10:45 tomeu dunno
10:45 gregdek Sigh.
10:45 garycmartin Whats the alternative if folks don't link updater?
10:45 (like)
10:45 gregdek So this, it seems to me, is a gigantic can of worms.
10:45 erikos gregdek: it is absolutey
10:46 gregdek: has the xo-rpm issues as well
10:46 gregdek Although putting it off indefinitely is inviting disaster, I suppose.
10:46 Heh.  Ayup.
10:47 I don't even know where we'd start such a discussion.
10:47 garycmartin Wow. that bad huh..
10:48 erikos tomeu: what is the state of addons?
10:48 tomeu I guess in the medium term we want to do exactly the same that firefox does
10:48 gregdek wonders if this is a discussion for FOSDEM.
10:48 tomeu erikos: didn't worked further on it, but others are, AFAIK
10:49 have a control panel module that queries via xml rpc or similar addons.s.o
10:49 erikos tomeu: that is?
10:49 tomeu: yeah, sounds good
10:50 tomeu: i don't want to maintain the wiki-xo structure
10:50 tomeu totally
10:50 gregdek OK, I've got to hit the road.
10:51 I've updated the development todo list, and I'll be sending out emails shortly.
10:51 erikos gregdek: you should ride more - not drive ;p
10:51 gregdek Maybe by next week we'll have enough bugs in sugarlabs trac to make noise about triagers?
10:52 (erikos: if I could ride, I would.)
10:52 erikos (gregdek: :))
10:53 gregdek All right folks.  Sorry it took a bit longer.  Let's drive some crazy triagers.  ;)
10:53 Oh!
10:53 erikos gregdek: yeah, i will work on the policies and work on a bugsquad meeting
10:53 gregdek Crap... SoaS!
10:53 erikos and that, outch lots to do...
10:53 gregdek None of this works without SoaS.  What's the status of the "beta" SoaS?
10:53 digs back in.
10:53 I guess marco was working on that?
10:54 erikos gregdek: right, and he will train me as a backup these days
10:54 gregdek: we will get there ;p
10:55 gregdek All right.
10:55 erikos gregdek: thanks for hosting us!
10:55 gregdek Well, I'll add it to the list and ping Marco about status, since it's now clearly critical path.  May be able to throw a volunteer at this too.
10:55 sdziallas might be able to lend a hand if it's Fedora-based; he's got some experience here.
10:55 As do others.
10:56 erikos that would be cool of course
10:56 gregdek Time to go.  Thanks all.  Same time next week.  ;)
10:56 #endmeeting

Index | Today     Channels | Search | Join

Powered by ilbot/Modified.
Webmaster