[Sugar-devel] Github issue tracking
Daniel Narvaez
dwnarvaez at gmail.com
Mon May 13 20:17:51 EDT 2013
On Monday, 13 May 2013, Manuel Quiñones wrote:
> 2013/5/11 William Orr <will at worrbase.com <javascript:;>>:
> >
> > Hello,
> >
> > Sticking with a privately controlled bug tracker is probably a good idea.
> > However, trac really needs to be cleaned up, as there are a ton of 3-5
> year
> > old bugs floating around that have long since been fixed. I've started
> > closing the few I can't reproduce in scm.
> >
> > As a new contributor, I initially had gotten the impression that no one
> used
> > trac, and I was discouraged from reporting/fixing bugs there.
>
> Things we can do to improve the poor state of trac:
>
> - make Milestone 1.0 the recommended trac view http://tinyurl.com/ckuk7cq
> - ask the infra team to make the above filter very visible in the trac
> homepage
> - bugs detected in sugar-build should be reported as 1.0
> - add a note about this recommendations in sugar-docs
>
> I closed a lot of obsolete bugs filed in Browse component. But I see
> two problems trying to clean all trac:
>
> 1. it is a lot of work, who is going to do it?
>
> 2. it is used for several things. There are many components, not only
> for sugar or activities, but for infra, for funding, distros, etc.
>
> That's why I suggest to provide the right view for developers instead.
>
I agree that we need to come up with the right query and publicize it
(perhaps we can make it the default too?).
Though I'm wondering, why a milestone instead of a list of components? Is
it because triaging existing bugs would be too much work? How are bugs
going to be added to the 1.0 list? Or is it only for developers-reported
stuff? Who is going to look at bugs not on 1.0?
Lots of questions sorry :)
--
Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130514/39ffe6eb/attachment-0001.html>
More information about the Sugar-devel
mailing list