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

[David Farning]

> -----Original Message-----
> From: sugar-devel-bounces at lists.sugarlabs.org [mailto:sugar-devel-
> bounces at lists.sugarlabs.org] On Behalf Of Simon Schampijer
> Sent: Tuesday, May 31, 2011 10:05 AM
> To: sugar-devel at lists.sugarlabs.org
> Subject: Re: [Sugar-devel] Sugar Labs bug tracker used by the OLPCA team?
> 
> 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.

I think this is the correct (first draft) approach. It enables OLPC-A to build
on the infrastructure and other shared resources Sugar Labs makes available
without adding (or even appearing to add) internal process overhead to the
community.

I suggest waiting a few months to see how things settle out and then revist the
issue with a refined workflow in August if necessary.

david