On Dec 29, 2010, at 6:21 PM, Yawar Amin wrote: > Hi Mike, > > I’m just playing devil’s advocate here, looking for a way to ‘trim the fat’ > from the bug list, since this is an interesting issue for us. Let me try to > answer some of your points. > > On 2010-12-29, at 20:04, Mike Alexander wrote: > >>> […] >> >> […] I sometimes find bugs in parts of the code that I don't understand well >> or have no immediate plans to work on. You think I shouldn't report them >> just because I'm a developer? > > You could perhaps post it to gnucash-devel. It could be argued anyway that at > this point it’s a vague, amorphous idea. When several devs have discussed and > agreed on it, someone could then open a bug and attach a (preliminary) patch. > From what I’ve seen, a lot of the time this is indeed what happens, anyway. > >> Or maybe I think I know how to fix it, but it will take a while to code and >> test properly. A bug report is useful in that case to let others know that >> it's a known problem which is being worked on. > > Yes, but all I’m suggesting in this scenario is that it be a bug report with > a patch attached, even if it’s a horrible/bad/broken patch. This at least > shows that someone has or had the intention to work on it, and lets someone > else come in and immediately get a clear idea of what the fix is trying to do. > > I myself am guilty of opening and ‘abandoning’ bugs with the intention of > coming back later to resolve them. I personally want to break the habit. > Anyone else?
Yawar, Bugs and enhancements are different and should be treated differently: Bugs (defects) should be reported ASAP so that everyone (including users) can see them. They shouldn't be closed as "won't fix" without a very good reason, if at all. They should be reviewed by a dev ASAP and have a milestone set on them if the fix isn't immediately obvious, (or is obviously someone else's job: For example, quartz port bugs are mine because no one else works on a mac). Enhancement requests are suggestions for improvement. We might decide (collectively or individually) that one isn't where we want to take Gnucash, or that it isn't practical, or that it isn't well enough defined. It does make some sense to put a time limit on them. There's seldom a reason for someone with commit privs to submit a patch unless he's unsure about the broader impact of something and wants another dev to review it. A bad patch runs the risk of another dev seeing it, not realizing that it's bad, and committing it for you (although you could review it yourself and mark it "needs work"). If you want to break your bad habit, when you submit an enhancement that you want to work on later, mark it assigned and assign it to yourself. Save a bug list that lists all of the bugs assigned to you, and make it a habit to review it once a month, and if you change your mind about one, close it. Posting here serves only for immediate discussion. While it is archived, I don't think anyone trolls through the archives looking for stray bugs or enhancements that haven't made it into Bugzilla, and we generally encourage people to file bugs or enhancements so that they can be easily reviewed. Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
