<div dir="ltr"><div>Shall we schedule something? What would be a good time to do this? I'm pretty flexible. </div>-walter </div><div class="gmail_extra"> <div class="gmail_quote">On Wed, May 15, 2013 at 6:32 PM, William Orr <<a href="mailto:will@worrbase.com" target="_blank">will@worrbase.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I can definitely help triage whenever you have this next meeting, depending on when it is. <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Daniel Narvaez <mailto:<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>> Tuesday, May 14, 2013 4:39 PM<div class="im"> On Tuesday, 14 May 2013, Walter Bender wrote: </div><div class="im"> Might make sense to do one earlier this time to clean up the mess. Especially if a non coder is willing to take the lead :) Anyone?? -- Daniel Narvaez </div><div class="im"> _______________________________________________ Sugar-devel mailing list <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </div> Walter Bender <mailto:<a href="mailto:walter.bender@gmail.com" target="_blank">walter.bender@gmail.com</a>> Tuesday, May 14, 2013 10:21 AM<div class="im"> On Tue, May 14, 2013 at 9:23 AM, Daniel Narvaez <<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a> <mailto:<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>>> wrote: On Tuesday, 14 May 2013, Walter Bender wrote: I think what would really help, independent of where/how we host things, is to instituteA more regular (and inclusive) triage meetings. I cannot think of the last time we had one that was announced on sugar-devel How did they go when they was organised? I think they would very helpful if the community participates. If its just the same people which writes code, then I think their time is better spent fixing bugs, reviewing and writing automated tests. We would have them in association with the release process. As I recall, we held them after feature freeze and again closer to the release date. It was in large part the coders, but not exclusively, and it gave others a chance to chime in regarding priorities. We'd generally meet for about 3 hours on a weekend. </div><div class="im"> -walter -- Daniel Narvaez -- Walter Bender Sugar Labs <a href="http://www.sugarlabs.org" target="_blank">http://www.sugarlabs.org</a> </div> Daniel Narvaez <mailto:<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>> Tuesday, May 14, 2013 9:23 AM<div class="im"> On Tuesday, 14 May 2013, Walter Bender wrote: </div><div class="im"> How did they go when they was organised? I think they would very helpful if the community participates. If its just the same people which writes code, then I think their time is better spent fixing bugs, reviewing and writing automated tests. </div> -- Daniel Narvaez Walter Bender <mailto:<a href="mailto:walter.bender@gmail.com" target="_blank">walter.bender@gmail.com</a>> Tuesday, May 14, 2013 9:14 AM<div class="im"> On Tuesday, 14 May 2013, Manuel Quiñones wrote: 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> </div> <<a href="http://bugs.sugarlabs.org" target="_blank">http://bugs.sugarlabs.org</a>> will want to do is to report a sugar<div class="im"> 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"> 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). </div><div class="im"> 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. -- Daniel Narvaez _______________________________________________ Sugar-devel mailing list <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a> </div> <mailto:<a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a>> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> 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. -walter<div class="im"> -- Walter Bender Sugar Labs <a href="http://www.sugarlabs.org" target="_blank">http://www.sugarlabs.org</a> </div><div class="im"> _______________________________________________ Sugar-devel mailing list <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </div> Daniel Narvaez <mailto:<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>> Tuesday, May 14, 2013 9:06 AM<div class="im"> On Tuesday, 14 May 2013, Manuel Quiñones wrote: </div> 2013/5/13 Daniel Narvaez <<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a> <javascript:;>>:<div class="im"> > > > On Monday, 13 May 2013, Manuel Quiñones wrote: >> </div> >> 2013/5/11 William Orr <<a href="mailto:will@worrbase.com" target="_blank">will@worrbase.com</a> <javascript:;>>:<div><div class="h5"> >> > >> > 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 <a href="http://tinyurl.com/ckuk7cq" target="_blank">http://tinyurl.com/ckuk7cq</a> >> - 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. </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> <<a href="http://bugs.sugarlabs.org" target="_blank">http://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 class="im"> > 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). 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. -- Daniel Narvaez </div></blockquote> </blockquote></div> -- Walter Bender Sugar Labs <a href="http://www.sugarlabs.org">http://www.sugarlabs.org</a> </div>