[Sugar-devel] Github issue tracking

[Manuel Quiñones]

2013/5/14 Daniel Narvaez <dwnarvaez at gmail.com>:
> On Tuesday, 14 May 2013, Manuel Quiñones wrote:
>>
>> 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.
>>
>
> I know but isn't that a good default view anyway? I mean, what most people
> going to bugs.sugarlabs.org will want to do is to report a sugar bug. The
> other stuff share the same tracker for convenience, but I'd say they are
> secondary. These other things could link to some query rather than to the
> homepage.

Yeah I agree is a good default.

>>
>> > 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 .
>
>
> I tend to think the honest thing to do if we are not going to look at bugs
> is either to just close them or to mark them as needs-triage and exclude
> them from the main query.
>
> It might piss off reporters, but we can ask for help with triage when they
> complain. I mean it sucks, but just silently ignoring the bugs is even
> worst.
>
> Also we can ask everyone help with triaging before we go ahead and close. If
> people helps out great, otherwise well...
>
> My opinion is that a bug tracker is useful only if all the bugs it contains
> are active. Better to close very aggressively than to lose important stuff
> in the mess of things that you alreay know will never be looked at. Zero
> bugs should be the goal, not tracking everything for the sake of it (like
> most open source projects do :p).

So let's go back to triage meetings and hope people attend.  I agree
we should close very aggressively, but we should give a little read
before to not loose historical valuable information.

>> 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
>
>
> I think this is asking too much to reporter. Very few people are likely to
> do it. IMO the most help we can ask to the reporter with triaging is to
> choose a component between sugar and a list of activity names, the version
> of sugar they was using, posssibly avoid duplicates. They are not going to
> know more than that.

Yes, agreed here too.

--
.. manuq ..