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

[Simon Schampijer]

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'.

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.

Regards,
    Simon
Regards,
    Simon