[Sugar-devel] Sugar Labs bug tracker used by the OLPCA team?

[Simon Schampijer]

On 05/31/2011 02:09 AM, Rafael Ortiz wrote:
> On Mon, May 30, 2011 at 6:12 PM, James Cameron<quozl at laptop.org>  wrote:
>
>> On Mon, May 30, 2011 at 04:52:51PM -0500, Rafael Ortiz wrote:
>>> Although, I really like this QA workflow, I'm not sure if this will
>>> prevent people from the community to follow the workflow, e.g an
>>> ''outsider'' or an activity developer that wants to close a bug or do
>>> follow-ups that require a change of state on the workflow. For
>>> starters there should be a wiki page where to document this in order
>>> to point people to the process.
>>>
>>> In my opinion this could be yet another wall to enter sugar
>>> development.
>>
>> I agree.
>>
>> I also don't like the workflow.  I think organisations should use their
>> own trackers to represent work they plan to do for themselves, and use
>> Sugar tracker as well for work that Sugar Labs may be involved in.
>>
>> Thus a ticket in the Sugar Labs tracker would be closed when the problem
>> is fixed to the satisfaction of Sugar Labs.  (e.g. fix committed to git).
>>
>> Thus a ticket in the downstream organisation tracker would be closed
>> when the problem is fixed to the satisfaction of the downstream
>> organisation.  (e.g. tested on hardware).
>>
>> I don't think it is likely that these events will happen at the same
>> time, or in the same sequence, and so I don't think it is right to delay
>> closure.
>>
>> This plan may expose the Sugar Labs tracker to a lot more event data
>> that doesn't really benefit the Sugar Labs community that much.
>>
>> If Sugar Labs is happy with it, go for it.  I'll work within the
>> restrictions.  I don't have to like it though.
>>
>>
> Fully agree with your comments. I'd prefer we don't use this workflow, but
> that's my way of viewing it, so community will have to decide.

I understand your concerns. Ideally upstream (SL) would be independent 
from the downstream (OLPCA). And maybe this is a bit sneaky.

So, the current situation in the SL tracker is that it is not taken care 
of much. For example, I have seen that since the review happens on the 
mailing list tickets does not get closed as much anymore. So the benefit 
for SL would be that people help to keep the bug database clean and 
getting free QA.

For OLPCA it gets easier since I do not have to open duplicates to 
trigger the status (either using a one ticket at the OLPC-bug-tracker 
per ticket on the SL-bug-tracker procedure or a multi-SL tickets in one 
OLPCA ticket procedure).

Regards,
    Simon