From Sugar Labs

Minutes at BugSquad/Meetings/Minutes/2008-12-10

SL Community Bugsquad

Intention

The BugSquad keeps track of current bugs in the sugar software and try to make sure that bugs are triaged correctly. You do not need any programming knowledge to be in the Bugsquad; in fact it is a great way to return something to the Sugar community if you cannot program. The squad is modeled on the gnome bugsquad: http://developer.gnome.org/projects/bugsquad/

• and what do we want it to become? Is this a sufficient discription?

Testing: upstream/downstream

• Who tests activities?
  • I was almost convinced that it is a downstream task but... OLPC does not support activities (it's an odd case, I know of no downstream project in the same situation). I've seen Mchua's post about moving it to Sugar Labs, let's make a good plan on it Wed. User:Marcopg
  • I think that Activities should be tested by individual Activity project groups, since Activities are independent subprojects. I don't think that the core Sugar Labs bugsquad should be testing Activities. I also don't think that internal OLPC QA should be testing Activities, other than making sure the ones we ship are ship-quality on XOs (by coordinating with the individual Activity projects, ideally).

• Making Activities platform-independent
  • The question of "who tests Activities?" is somewhat related to the issue of making activities platform independent, similarly to firefox plugins (I will elaborate on it in the meeting). User:Marcopg

• If we move activities testing upstream, how do we move tickets? If we don't move them, where should user oriented information be hosted?
  • (not very clear on this, and it's not strictly a testing issue but it certainly intersects with it). User:Marcopg

• We should report tickets upstream as much as possible, but how do we ensure downstream is able to track those which are interesting to them?
  • If OLPC misses a fix because it cares about because it's tracked only upstream we are going to be in troubles  :) For the record: Greg suggestion: don't try too hard to solve the issue because it's largely an unsolved one in foss. User:Marcopg
  • The responsibility burden for this falls on downstream, in my opinion. Mchua 07:28, 6 December 2008 (UTC)

• How does a tester know a problem is very likely downstream?
  • garycmartin just reported an hardware related issue to dev.sl.o, that's something we can certainly avoid with simple guidelines. Action item -> write down such guidelines! User:Marcopg
  • This is a big question for me, because I think the "how do we ensure downstream is able to track those which are interesting to them?" problem is something that's downstream's problem, and downstream is currently me. ;) Mchua 07:28, 6 December 2008 (UTC)

• How can we manage expectations?
  • It's going to be hard at the beginning, both for developers and testers. We need to manage expectations so that we don't make people upset. Worth considering a mailing list post explaining what is going on, what we are planning to do about it, and to please be patient while things settle down. Show the positive side of it! User:Marcopg

• How do we ensure that OLPC is comfortable with what we are doing?
  • This matters because OLPC is currently Sugar's largest downstream user by far. I'll try to raise the topic at the internal OLPC QA meeting this coming Monday. Mchua