<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 14, 2013 at 9:06 AM, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tuesday, 14 May 2013, Manuel Quiñones wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 2013/5/13 Daniel Narvaez <<a>dwnarvaez@gmail.com</a>>:<br> ><br> ><br> > On Monday, 13 May 2013, Manuel Quiñones wrote:<br> >><br> >> 2013/5/11 William Orr <<a>will@worrbase.com</a>>:<br> >> ><br> >> > Hello,<br> >> ><br> >> > Sticking with a privately controlled bug tracker is probably a good<br> >> > idea.<br> >> > However, trac really needs to be cleaned up, as there are a ton of 3-5<br> >> > year<br> >> > old bugs floating around that have long since been fixed. I've started<br> >> > closing the few I can't reproduce in scm.<br> >> ><br> >> > As a new contributor, I initially had gotten the impression that no one<br> >> > used<br> >> > trac, and I was discouraged from reporting/fixing bugs there.<br> >><br> >> Things we can do to improve the poor state of trac:<br> >><br> >> - make Milestone 1.0 the recommended trac view <a href="http://tinyurl.com/ckuk7cq" target="_blank">http://tinyurl.com/ckuk7cq</a><br> >> - ask the infra team to make the above filter very visible in the trac<br> >> homepage<br> >> - bugs detected in sugar-build should be reported as 1.0<br> >> - add a note about this recommendations in sugar-docs<br> >><br> >> I closed a lot of obsolete bugs filed in Browse component. But I see<br> >> two problems trying to clean all trac:<br> >><br> >> 1. it is a lot of work, who is going to do it?<br> >><br> >> 2. it is used for several things. There are many components, not only<br> >> for sugar or activities, but for infra, for funding, distros, etc.<br> >><br> >> That's why I suggest to provide the right view for developers instead.<br> ><br> ><br> > I agree that we need to come up with the right query and publicize it<br> > (perhaps we can make it the default too?).<br> <br> The problem setting it as default is that trac is used for other<br> things, not just sugar or activity code. There are "third party"<br> activities, funding requests, deploys stuff etc. But yes the<br> "developers view" should be on top of the homepage, I think.<br> <br></blockquote><div><br></div></div></div><div>I know but isn't that a good default view anyway? I mean, what most people going to <a href="http://bugs.sugarlabs.org" target="_blank">bugs.sugarlabs.org</a> 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.</div> <div class="im"> <div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > Though I'm wondering, why a milestone instead of a list of components? Is it<br> > because triaging existing bugs would be too much work? How are bugs going to<br> > be added to the 1.0 list? Or is it only for developers-reported stuff? Who<br> > is going to look at bugs not on 1.0?<br> <br> I was thinking in a milestone to cut-off the old/obsolete bugs. We<br> already did for 0.98 . </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div><br></div></div><div>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.</div> <div> </div><div>It might piss off reporters, but we can ask for help with triage when they complain. I mean it sucks, but just silently <span></span>ignoring the bugs is even worst.</div><div><br></div><div>Also we can ask everyone help with triaging before we go ahead and close. If people helps out great, otherwise well...</div> <div><br></div><div>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).</div> <div class="im"> <div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ideally before submitting to 1.0 the reporter<br> should:<br> <br> - do a search to see if its not reported<br> - if is not reported, file it as 1.0<br> - if is reported, move it to 1.0 and add a comment that this bug<br> is still happening<br> </blockquote><div><br></div></div><div>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. </div> <span class="HOEnZb"><font color="#888888"> <br><br>-- <br>Daniel Narvaez<br><br> </font></span><br>_______________________________________________<br> Sugar-devel mailing list<br> <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br> <br></blockquote><div><br></div><div>I think what would really help, independent of where/how we host things, is to institute more regular (and inclusive) triage meetings. I cannot think of the last time we had one that was announced on sugar-devel.<br> <br></div><div>-walter<br></div></div><br><br clear="all"><br>-- <br>Walter Bender<br>Sugar Labs<br><a href="http://www.sugarlabs.org">http://www.sugarlabs.org</a><br> </div></div>