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

Rafael Ortiz rafael at activitycentral.com
Tue May 31 13:51:40 EDT 2011


On Tue, May 31, 2011 at 9:05 AM, Simon Schampijer <simon at schampijer.de>wrote:

> On 05/31/2011 10:58 AM, Simon Schampijer wrote:
>
>> 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
>>
>
> Ok, I think I step back on my initial proposal and just go with tagging the
> tickets (keywords) we are interested in with '11.2.0'.
>
> +1 that's what we have also for dextrose.


> As we need to as well triage the 'priority' field for bugs based on our
> release goals we need to rely on our bug tracker anyhow. For new tickets we
> will try and file them at the sl tracker and duplicate the tickets important
> for us on the olpc tracker. Let's see if that works out for us.
>
> sounds good.
 cheers

> Regards,
>   Simon
>
> Regards,
>   Simon
>
>
>
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20110531/46c7484c/attachment-0001.html>


More information about the Sugar-devel mailing list