Re: [Sugar-devel] Github issue tracking
2013/5/15 Walter Bender walter.ben...@gmail.com: Shall we schedule something? What would be a good time to do this? I'm pretty flexible. What about same day and hour of previous html meeting? Monday 20 May 2013 - 14:00 UTC -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Github issue tracking
Monday is not ideal for me, but unless someone comes up with another date/time, let's do it. -walter On Thu, May 16, 2013 at 10:52 AM, Manuel Quiñones ma...@laptop.org wrote: 2013/5/15 Walter Bender walter.ben...@gmail.com: Shall we schedule something? What would be a good time to do this? I'm pretty flexible. What about same day and hour of previous html meeting? Monday 20 May 2013 - 14:00 UTC -- .. manuq .. -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Github issue tracking
Shall we schedule something? What would be a good time to do this? I'm pretty flexible. -walter On Wed, May 15, 2013 at 6:32 PM, William Orr w...@worrbase.com wrote: I can definitely help triage whenever you have this next meeting, depending on when it is. Daniel Narvaez mailto:dwnarv...@gmail.com Tuesday, May 14, 2013 4:39 PM On Tuesday, 14 May 2013, Walter Bender wrote: 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 __**_ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.**org Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/**listinfo/sugar-develhttp://lists.sugarlabs.org/listinfo/sugar-devel Walter Bender mailto:walter.bender@gmail.**com walter.ben...@gmail.com Tuesday, May 14, 2013 10:21 AM On Tue, May 14, 2013 at 9:23 AM, Daniel Narvaez dwnarv...@gmail.commailto: dwnarv...@gmail.com 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. -walter -- Daniel Narvaez -- Walter Bender Sugar Labs http://www.sugarlabs.org Daniel Narvaez mailto:dwnarv...@gmail.com Tuesday, May 14, 2013 9:23 AM On Tuesday, 14 May 2013, Walter Bender wrote: 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. -- Daniel Narvaez Walter Bender mailto:walter.bender@gmail.**com walter.ben...@gmail.com Tuesday, May 14, 2013 9:14 AM 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 bugs.sugarlabs.org http://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. 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). 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 Sugar-devel@lists.sugarlabs.**org Sugar-devel@lists.sugarlabs.org mailto:Sugar-devel@lists.**sugarlabs.orgSugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/**listinfo/sugar-develhttp://lists.sugarlabs.org/listinfo/sugar-devel 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 -- Walter Bender Sugar Labs http://www.sugarlabs.org __**_ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.**org Sugar-devel@lists.sugarlabs.org
Re: [Sugar-devel] Github issue tracking
I agree with the need of cleanup the bug database. I have proposed that several times, and closed many bugs. One of the best arguments I read about this topic, is the bug bankrupcy description: *The bug database* is obviously a great thing to have. Bug reports should be complete, accurate, and actionable. But I have noticed that in many real-world companies, the desire never to miss any bug report leads to bug bankrupcy, where you wake up one day and discover that there are 3000 open bugs in the database, some of which are so old they may not apply any more, some of which can never be reproduced, and most of which are not even worth fixing because they’re so tiny. When you look closely you realize that months or years of work has gone into preparing those bug reports, and you ask yourself, how could we have 3000 bugs in the database while our product is delightful and customers love it and use it every day? [1] I have prepared two reports to try to understand better our actual situation: Bugs by components [2] This report show activities are usually in a good shape (that was not always true) Of course, sugar* + journal are much more complex. If we do some triage, should be good concentrate on these components Bugs by sugar version [3] Nobody is working in fix bugs of sugar older than 0.98. We should check if the older bugs are still present or close them. Gonzalo [1] http://www.joelonsoftware.com/items/2012/07/09.html [2] http://bugs.sugarlabs.org/report/14 [3] http://bugs.sugarlabs.org/report/13 On Tue, May 14, 2013 at 11:21 AM, Walter Bender walter.ben...@gmail.comwrote: On Tue, May 14, 2013 at 9:23 AM, Daniel Narvaez dwnarv...@gmail.comwrote: 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. -walter -- Daniel Narvaez -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Github issue tracking
Ah! Thanks for posting this, I knew Joel had something like this but I
couldn't find it anymore.
On Tuesday, 14 May 2013, Gonzalo Odiard wrote:
I agree with the need of cleanup the bug database. I have proposed that
several times,
and closed many bugs. One of the best arguments I read about this topic,
is the bug bankrupcy description:
*The bug database* is obviously a great thing to have. Bug reports
should be complete, accurate, and actionable. But I have noticed that in
many real-world companies, the desire never to miss any bug report leads to
bug bankrupcy, where you wake up one day and discover that there are 3000
open bugs in the database, some of which are so old they may not apply any
more, some of which can never be reproduced, and most of which are not even
worth fixing because they’re so tiny. When you look closely you realize
that months or years of work has gone into preparing those bug reports, and
you ask yourself, how could we have 3000 bugs in the database while our
product is delightful and customers love it and use it every day? [1]
I have prepared two reports to try to understand better our actual
situation:
Bugs by components [2]
This report show activities are usually in a good shape (that was not
always true)
Of course, sugar* + journal are much more complex.
If we do some triage, should be good concentrate on these components
Bugs by sugar version [3]
Nobody is working in fix bugs of sugar older than 0.98.
We should check if the older bugs are still present or close them.
Gonzalo
[1] http://www.joelonsoftware.com/items/2012/07/09.html
[2] http://bugs.sugarlabs.org/report/14
[3] http://bugs.sugarlabs.org/report/13
On Tue, May 14, 2013 at 11:21 AM, Walter Bender
walter.ben...@gmail.comjavascript:_e({}, 'cvml',
'walter.ben...@gmail.com');
wrote:
On Tue, May 14, 2013 at 9:23 AM, Daniel Narvaez
dwnarv...@gmail.comjavascript:_e({}, 'cvml', 'dwnarv...@gmail.com');
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.
-walter
--
Daniel Narvaez
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org javascript:_e({}, 'cvml',
'Sugar-devel@lists.sugarlabs.org');
http://lists.sugarlabs.org/listinfo/sugar-devel
--
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Github issue tracking
On Tuesday, 14 May 2013, Walter Bender wrote:
On Tue, May 14, 2013 at 9:23 AM, Daniel Narvaez
dwnarv...@gmail.comjavascript:_e({}, 'cvml', 'dwnarv...@gmail.com');
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.
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
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Github issue tracking
On Sunday, 12 May 2013, William Orr wrote: Simon Schampijer mailto:si...@schampijer.de May 11, 2013 11:55 AM Am 11.05.2013 um 16:45 schrieb Daniel Draked...@laptop.org: On Sat, May 11, 2013 at 4:15 AM, Daniel Narvaezdwnarv...@gmail.com wrote: https://github.com/sugarlabs/**sugar-toolkit-gtk3/issues/27https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/27 We should probably decide if we want to keep using trac instead and if so turn the issue tracker on github off. Last time we discussed it, the idea was to keep using trac to not depend too much on closed source github. What are people thoughts these days? I would prefer to stay with trac, to avoid a split/migration, to keep the info on the tickets directly under our control, and to keep with our open source ideals. Daniel I wanted to give it a try to see how it works at least, going through the process with this ticket. I am not opposed to stay with trac though. Simon __**_ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/**listinfo/sugar-develhttp://lists.sugarlabs.org/listinfo/sugar-devel __**_ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/**listinfo/sugar-develhttp://lists.sugarlabs.org/listinfo/sugar-devel Daniel Drake mailto:d...@laptop.org May 11, 2013 10:45 AM I would prefer to stay with trac, to avoid a split/migration, to keep the info on the tickets directly under our control, and to keep with our open source ideals. Daniel __**_ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/**listinfo/sugar-develhttp://lists.sugarlabs.org/listinfo/sugar-devel Daniel Narvaez mailto:dwnarv...@gmail.com May 11, 2013 6:15 AM Hello, I noticed people have started to report issues on github. https://github.com/sugarlabs/**sugar-toolkit-gtk3/issues/27https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/27 We should probably decide if we want to keep using trac instead and if so turn the issue tracker on github off. Last time we discussed it, the idea was to keep using trac to not depend too much on closed source github. What are people thoughts these days? Personally I like github issue tracking a lot, though I see the point about it being closed source and I imagine a migration would be a bit of a pain. -- Daniel Narvaez __**_ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/**listinfo/sugar-develhttp://lists.sugarlabs.org/listinfo/sugar-devel 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. Yes, I couldnt agree more! -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Github issue tracking
There seem to be consensus about keeping to use trac, so I went ahead and disabled all the github issue trackers. On Saturday, 11 May 2013, Daniel Narvaez wrote: Hello, I noticed people have started to report issues on github. https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/27 We should probably decide if we want to keep using trac instead and if so turn the issue tracker on github off. Last time we discussed it, the idea was to keep using trac to not depend too much on closed source github. What are people thoughts these days? Personally I like github issue tracking a lot, though I see the point about it being closed source and I imagine a migration would be a bit of a pain. -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Github issue tracking
Hello, I noticed people have started to report issues on github. https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/27 We should probably decide if we want to keep using trac instead and if so turn the issue tracker on github off. Last time we discussed it, the idea was to keep using trac to not depend too much on closed source github. What are people thoughts these days? Personally I like github issue tracking a lot, though I see the point about it being closed source and I imagine a migration would be a bit of a pain. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Github issue tracking
On Sat, May 11, 2013 at 4:15 AM, Daniel Narvaez dwnarv...@gmail.com wrote: https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/27 We should probably decide if we want to keep using trac instead and if so turn the issue tracker on github off. Last time we discussed it, the idea was to keep using trac to not depend too much on closed source github. What are people thoughts these days? I would prefer to stay with trac, to avoid a split/migration, to keep the info on the tickets directly under our control, and to keep with our open source ideals. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Github issue tracking
Am 11.05.2013 um 16:45 schrieb Daniel Drake d...@laptop.org: On Sat, May 11, 2013 at 4:15 AM, Daniel Narvaez dwnarv...@gmail.com wrote: https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/27 We should probably decide if we want to keep using trac instead and if so turn the issue tracker on github off. Last time we discussed it, the idea was to keep using trac to not depend too much on closed source github. What are people thoughts these days? I would prefer to stay with trac, to avoid a split/migration, to keep the info on the tickets directly under our control, and to keep with our open source ideals. Daniel I wanted to give it a try to see how it works at least, going through the process with this ticket. I am not opposed to stay with trac though. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Github issue tracking
Simon Schampijer mailto:si...@schampijer.de May 11, 2013 11:55 AM Am 11.05.2013 um 16:45 schrieb Daniel Draked...@laptop.org: On Sat, May 11, 2013 at 4:15 AM, Daniel Narvaezdwnarv...@gmail.com wrote: https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/27 We should probably decide if we want to keep using trac instead and if so turn the issue tracker on github off. Last time we discussed it, the idea was to keep using trac to not depend too much on closed source github. What are people thoughts these days? I would prefer to stay with trac, to avoid a split/migration, to keep the info on the tickets directly under our control, and to keep with our open source ideals. Daniel I wanted to give it a try to see how it works at least, going through the process with this ticket. I am not opposed to stay with trac though. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Daniel Drake mailto:d...@laptop.org May 11, 2013 10:45 AM I would prefer to stay with trac, to avoid a split/migration, to keep the info on the tickets directly under our control, and to keep with our open source ideals. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Daniel Narvaez mailto:dwnarv...@gmail.com May 11, 2013 6:15 AM Hello, I noticed people have started to report issues on github. https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/27 We should probably decide if we want to keep using trac instead and if so turn the issue tracker on github off. Last time we discussed it, the idea was to keep using trac to not depend too much on closed source github. What are people thoughts these days? Personally I like github issue tracking a lot, though I see the point about it being closed source and I imagine a migration would be a bit of a pain. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel 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. -- William Orr ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
