[Sugar-devel] Github issue tracking

[Manuel Quiñones]

2013/5/13 Daniel Narvaez <dwnarvaez at gmail.com>:
>
>
> On Monday, 13 May 2013, Manuel Quiñones wrote:
>>
>> 2013/5/11 William Orr <will at worrbase.com>:
>> >
>> > 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?).

The problem setting it as default is that trac is used for other
things, not just sugar or activity code.  There are "third party"
activities, funding requests, deploys stuff etc.  But yes the
"developers view" should be on top of the homepage, I think.

> 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?

I was thinking in a milestone to cut-off the old/obsolete bugs.  We
already did for 0.98 .  Ideally before submitting to 1.0 the reporter
should:

- do a search to see if its not reported
    - if is not reported, file it as 1.0
    - if is reported, move it to 1.0 and add a comment that this bug
is still happening

--
.. manuq ..