Difference between revisions of "BugSquad/Meetings/Agendas/2008-12-10"
Jump to navigation
Jump to search
m (/2008-12-10 moved to TestingTeam/Meetings/Agendas/2008-12-10) |
|||
Line 1: | Line 1: | ||
− | * Who tests activities? | + | * SL Community Bugsquad: what is it now, and what do we want it to become? |
− | ** 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 [[User:Mchua|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). | + | * Testing: upstream/downstream |
− | * 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]] | + | ** Who tests activities? |
− | * If we move activities testing upstream, how do we move tickets? If we don't move them, where should user oriented information be hosted? | + | *** 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 [[User:Mchua|Mchua's]] post about moving it to Sugar Labs, let's make a good plan on it Wed. [[User:Marcopg]] |
− | ** (not very clear on this, and it's not strictly a testing issue but it certainly intersects with it). [[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). |
− | * 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]] | + | ** Making Activities platform-independent |
− | ** The responsibility burden for this falls on downstream, in my opinion. [[User:Mchua|Mchua]] 07:28, 6 December 2008 (UTC) | + | *** 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]] |
− | * 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]] | + | ** If we move activities testing upstream, how do we move tickets? If we don't move them, where should user oriented information be hosted? |
− | ** 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. ;) [[User:Mchua|Mchua]] 07:28, 6 December 2008 (UTC) | + | *** (not very clear on this, and it's not strictly a testing issue but it certainly intersects with it). [[User:Marcopg]] |
− | * 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]] | + | ** 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? |
− | * How do we ensure that OLPC is comfortable with what we are doing? | + | *** 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]] |
− | ** 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. [[User:Mchua|Mchua]] | + | *** The responsibility burden for this falls on downstream, in my opinion. [[User:Mchua|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. ;) [[User:Mchua|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. [[User:Mchua|Mchua]] |
Revision as of 09:28, 8 December 2008
- SL Community Bugsquad: what is it now, and what do we want it to become?
- 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).
- Who tests activities?
- 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
- Making Activities platform-independent
- 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
- If we move activities testing upstream, how do we move tickets? If we don't move them, where should user oriented information be hosted?
- 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)
- 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?
- 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 does a tester know a problem is very likely downstream?
- 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 can we manage expectations?
- 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
- How do we ensure that OLPC is comfortable with what we are doing?