Re: [Sugar-devel] Q on tracker cleanup / triage
On 07/04/2010 01:11 AM, Tim McNamara wrote: Hi devs, 500+ unclosed bugs causes problems. I feel intimidated overwhelmed by this number. I also find it difficult to find material sift through bug reports, to find areas where I can help (although, at the moment, I'm quite content with sugar-love level problems). About 500+ bugs being hard to handle, I think that maybe what happens is that either those are not correctly categorized, or our tools are not making use of all info and thus unwanted results appear in our queries making difficult to find what we look for. However, 500+ bugs isn't that accurate. Some have been identified as upstream problems, but their resolution status remains open. As it has been said in another reply, sometimes we want to track upstream resolution status, and sometimes even a workaround in Sugar itself. I suggest that we make more use of the wontfix resolution status. In 5 minutes, I've found some likely candidates. wontfix comes with a high risk of alienating people submitting bugs, but a polite note saying that it's upstream or possibly something like Unfortunately, we have higher priority areas to work on right now. However we would welcome a patch if you are still wiling to work on this issue. It's great that you've taken the time to submit the bug, and we have looked into resolving things for you. Well, if we are willing to accept a patch to solve an issue, then I think that the issue is definitely worth an open ticket. Some candidates: Sorry, no net acces right now, will reply later about specific tickets. Thanks a lot for your interest in this very important topic, Tomeu wontfix - upstream http://bugs.sugarlabs.org/ticket/1307 wontfix - other priorities http://bugs.sugarlabs.org/ticket/288 http://bugs.sugarlabs.org/ticket/292 duplicates http://bugs.sugarlabs.org/ticket/172 http://bugs.sugarlabs.org/ticket/394 I think that resolving bugs, even if by using the wontfix tag will make other areas easier. Also, I don't know if I have the permission to change resolution status when something hasn't been touched for 12+ months. If I were to change status on likely candidates, would this anger the other developers? Tim ___ 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] Q on tracker cleanup / triage
On 07/04/2010 05:15 PM, Bernie Innocenti wrote: El Sun, 04-07-2010 a las 02:29 +0100, Gary Martin escribió: Also, I don't know if I have the permission to change resolution status when something hasn't been touched for 12+ months. If I were to change status on likely candidates, would this anger the other developers? I know it's sensitive, for us slightly more delicate souls, but if you feel strongly about a bug status... I'd say go for its change of status. It will trigger either action/indifference from genuinely interested parties, possibly patches/discussion, action, and glory ;) Yes, I would encourage users to apply the Be Bold mantra [1] to the bug tracker as well as the wiki. If in doubt, go ahead and change. If you were wrong, someone will revert your change. [1] http://en.wikipedia.org/wiki/Wikipedia:Be_bold Agreed as well, with the warning that if the changes are in mass and exceed the capacity of the rest of interested parties to react, review or revert those changes, it may not be such a good idea. Normally when developers get angry at some triaging activity it's because of automated changes, not because of spontaneous triaging. It seems fair to say there is some level of (completely understandable) analysis paralysis for some level of bugs. Bug triage activity is at a low at the moment. Don't apologise for bringing that task back up in everyones focus/face. Low? Not really: http://bugs.sugarlabs.org/timeline I'm offline right now so I cannot check (though I have seen lots of activity from you and Silbe in the past weeks, kudos!), but I would like to encourage people interested in triaging that read and improve http://wiki.sugarlabs.org/go/BugSquad/Triage_Guide so we follow a consistent set of guidelines and specially so bugs get out from the triaging queue once someone has been able to look at it. Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Q on tracker cleanup / triage
Excerpts from Tomeu Vizoso's message of Mon Jul 05 10:47:44 + 2010: [...] or possibly something like Unfortunately, we have higher priority areas to work on right now. Never close bugs because nobody has time to fix them. Rather use the priority field to indicate the maintainer isn't interested in working on the issue, but would welcome patches. Maybe s/maintainer/development team? Actually the priority field is something that nags me about our current bug tracker. It's a single field, but bugs have different priorities to different people. For example the issues with the NetworkManager integration are so annoying that they were (*) of high priority to me, but apparently not to other members of the Development Team; maybe because deployments have different network setups and the issues don't appear there. Guess we have enough bugs to have a triaging team (or bug squad, though I don't like the name) instead of just a bug master. I still think the activity (!= number of open bugs) on our bug tracker is low enough for a single person. It shouldn't take more than say an hour a day. Even Gentoo had a single bug master for a very long time. A triage team might help with cleaning up _old_ bugs, though. (*) I'm currently using system connections and cnetworkmanager so I can use IEEE 802.1x authentication on the university network instead of the buggy VPN client. This works significantly better than using Sugar-managed user connections. With user connections getting thrown out [1] of NetworkManager, quite a few of our problems might get solved for us (or be tackled by the rewrite of the NetworkManager integration that might be required). Sascha [1] http://live.gnome.org/NetworkManager/RemovingUserSettings signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Q on tracker cleanup / triage
El Sun, 04-07-2010 a las 02:29 +0100, Gary Martin escribió: Also, I don't know if I have the permission to change resolution status when something hasn't been touched for 12+ months. If I were to change status on likely candidates, would this anger the other developers? I know it's sensitive, for us slightly more delicate souls, but if you feel strongly about a bug status... I'd say go for its change of status. It will trigger either action/indifference from genuinely interested parties, possibly patches/discussion, action, and glory ;) Yes, I would encourage users to apply the Be Bold mantra [1] to the bug tracker as well as the wiki. If in doubt, go ahead and change. If you were wrong, someone will revert your change. [1] http://en.wikipedia.org/wiki/Wikipedia:Be_bold It seems fair to say there is some level of (completely understandable) analysis paralysis for some level of bugs. Bug triage activity is at a low at the moment. Don't apologise for bringing that task back up in everyones focus/face. Low? Not really: http://bugs.sugarlabs.org/timeline -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Q on tracker cleanup / triage
Hi devs, 500+ unclosed bugs causes problems. I feel intimidated overwhelmed by this number. I also find it difficult to find material sift through bug reports, to find areas where I can help (although, at the moment, I'm quite content with sugar-love level problems). However, 500+ bugs isn't that accurate. Some have been identified as upstream problems, but their resolution status remains open. I suggest that we make more use of the wontfix resolution status. In 5 minutes, I've found some likely candidates. wontfix comes with a high risk of alienating people submitting bugs, but a polite note saying that it's upstream or possibly something like Unfortunately, we have higher priority areas to work on right now. However we would welcome a patch if you are still wiling to work on this issue. It's great that you've taken the time to submit the bug, and we have looked into resolving things for you. Some candidates: wontfix - upstream http://bugs.sugarlabs.org/ticket/1307 wontfix - other priorities http://bugs.sugarlabs.org/ticket/288 http://bugs.sugarlabs.org/ticket/292 duplicates http://bugs.sugarlabs.org/ticket/172 http://bugs.sugarlabs.org/ticket/394 I think that resolving bugs, even if by using the wontfix tag will make other areas easier. Also, I don't know if I have the permission to change resolution status when something hasn't been touched for 12+ months. If I were to change status on likely candidates, would this anger the other developers? Tim ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Q on tracker cleanup / triage
Excerpts from Tim McNamara's message of Sat Jul 03 23:11:42 + 2010: Some have been identified as upstream problems, but their resolution status remains open. That's because they still affect users. Some might need Sugar changes once they have been handled upstream. The current status fields we use in Trac are inconsistent (probably for historic reasons). There's a better way (called Workflow [1]) to handle this now, but so far nobody had time to design a new set of status fields and matching Workflow for our Trac instance. Help in that area would be very welcome - especially if it has a good way of indicating that we are waiting for some other party (reporter, upstream, whatever) to do something. I suggest that we make more use of the wontfix resolution status. I recommend to use wontfix sparingly. It tends to alienate bug reporters (as you mention yourself further down). If it needs fixing in some component other than Sugar and we don't need to do anything once it has been fixed, please file a bug against the other component (i.e. upstream) and set resolution to NOTSUGAR. [...] or possibly something like Unfortunately, we have higher priority areas to work on right now. Never close bugs because nobody has time to fix them. Rather use the priority field to indicate the maintainer isn't interested in working on the issue, but would welcome patches. wontfix - upstream http://bugs.sugarlabs.org/ticket/1307 This isn't a clear one. Yes, Firefox also behaves this way - but that doesn't imply Browse _should_ do it. If we decide we want Browse to be different, there's a good chance we can add some code to achieve that. Mozilla won't change their code to accommodate our UI design decisions. wontfix - other priorities http://bugs.sugarlabs.org/ticket/288 The original request should be easy to handle. Turtle Art (or Turtle Blocks or whatever it's called now, can't remember) already has an icon with a snake that symbolises Python code. http://bugs.sugarlabs.org/ticket/292 #288 evolved into a more generic discussion, which is how to handle related MIME types (sub types, sibling types). #292 was opened to handle this broader issue. We might add a milestone 1.0 (or even after-1.0) to indicate this will need to be fixed eventually, but not right away. duplicates http://bugs.sugarlabs.org/ticket/172 http://bugs.sugarlabs.org/ticket/394 Duplicates are something a bug master would handle (by resolving bugs as duplicate and adding the reporter of the dupe to the CC list of the first filed ticket) if we had one. A bug master also ensures tickets are filed against the correct component and are (apparently) complete. In this particular case however the maintainer himself filed a second bug on purpose, so please don't mark it as duplicate. Also, I don't know if I have the permission to change resolution status when something hasn't been touched for 12+ months. If I were to change status on likely candidates, would this anger the other developers? You're free to handle most bugs in a way that helps resolving them. But I would advise against closing bugs as WONTFIX or similar unless you're sure the maintainer is of the same opinion. Sascha [1] https://bugs.sugarlabs.org/wiki/TracWorkflow -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Q on tracker cleanup / triage
On 4 Jul 2010, at 00:11, Tim McNamara paperl...@timmcnamara.co.nz wrote: Hi devs, 500+ unclosed bugs causes problems. I feel intimidated overwhelmed by this number. I also find it difficult to find material sift through bug reports, to find areas where I can help (although, at the moment, I'm quite content with sugar-love level problems). However, 500+ bugs isn't that accurate. Some have been identified as upstream problems, but their resolution status remains open. I suggest that we make more use of the wontfix resolution status. In 5 minutes, I've found some likely candidates. wontfix comes with a high risk of alienating people submitting bugs, but a polite note saying that it's upstream or possibly something like Unfortunately, we have higher priority areas to work on right now. However we would welcome a patch if you are still wiling to work on this issue. It's great that you've taken the time to submit the bug, and we have looked into resolving things for you. Some candidates: wontfix - upstream http://bugs.sugarlabs.org/ticket/1307 wontfix - other priorities http://bugs.sugarlabs.org/ticket/288 http://bugs.sugarlabs.org/ticket/292 duplicates http://bugs.sugarlabs.org/ticket/172 http://bugs.sugarlabs.org/ticket/394 I think that resolving bugs, even if by using the wontfix tag will make other areas easier. Also, I don't know if I have the permission to change resolution status when something hasn't been touched for 12+ months. If I were to change status on likely candidates, would this anger the other developers? I know it's sensitive, for us slightly more delicate souls, but if you feel strongly about a bug status... I'd say go for its change of status. It will trigger either action/indifference from genuinely interested parties, possibly patches/discussion, action, and glory ;) It seems fair to say there is some level of (completely understandable) analysis paralysis for some level of bugs. Bug triage activity is at a low at the moment. Don't apologise for bringing that task back up in everyones focus/face. Regards, --Gary Tim ___ 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
