Thomas, Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> In closing a bug report on bugzilla > (http://bugzilla.gnome.org/show_bug.cgi?id=150604), Derek Atkins asks > me: > >> Thomas: can you please attempt to verify bugs against cvs before you >> submit them? > > Really, probably, no. It's a bajillion times easier to report bugs > against the released version. I do not have the resources to keep a > running copy of the CVS head all the time, nor can I reasonably build > it every time I need to verify a bug. You're welcome to just keep the 1.8 (release) branch instead of CVS HEAD. It's only fair to _US_ that you verify that a bug exists before passing it on. Something like this would have been a simple source-code check to verify "oh, that's already been fixed." Having multiple builds is relatively easy. I've got /opt/gnucash-cvs, /opt/gnucash-1.8, and /opt/gnucash-g2 on my system. I can run whichever version I want by specifying the appropriate path. It works quite well for a number of people. > Heck, this is one of the reasons for having regular releases. ;) Releases require non-zero effort. It takes a good deal of time to get the translations finished, tag the release, re-test all the code, package it up, re-test the package, and then get it to our builders to make new packages. This detracts from the work we want to do -- getting the g2 port finished. We have precious few developer resources as it is to put out what many of us consider "frivolous releases". The 1.8 code is in "stable mode", which means releases every 3-6 months until the next major version, with (hopefully) minimal changes in each release. Version 1.8.9 was released 4 months ago, so we're still well within our goals. I would expect to see a 1.8.10 sometime in the Sept/Oct timeframe unless we can make a lot of progress and get 1.9.0 out. > I would be happy to check the ChangeLog and make an effort to see if > problems are fixed by source-perusal, because that doesn't require the > same level of ressources. Perusing ChangeLogs requires good GNU > ChangeLogs; in this case the entry Please do so! it would help all of us, and reduce the overall workload. > * Luigi Ballabio's automake patch to gnucash.m4 > > would not have told me at all what the fix was, and so I wouldn't be > able to tell whether the bug I reported were fixed or not. For which I appologize... I'll certainly try to be better with my messages. However a SOURCE perusal would have clearly shown you that this change had been made. > (But, of course, direct source perusal would; sometimes the source can > be hard to understand, however, so that obviously fails.) Sure. I don't expect you to re-verify everything, but something this simple that can be verified by a 10-second source-code perusal should never had made it into bugzilla. > I'm convincable, but it seems reasonable to me to verify bugs against > the release, before reporting them, rather than needing to deal with > the bleeding edge. I am willing to make an effort in the future to > see if they are fixed by source perusal as well if that is desired. I don't think it's reasonable.. Things in CVS have changed since the release -- indeed, they sometimes change as quickly as a day to a week after the release. Considering it's been four months, it should be expected that lots of changes have happenened.... Also, it's not too hard to have a second build-tree on your test machine where you can periodically cvs update and rebuild before passing a bug up to us. OTOH, it would CERTAINLY be reasonable to pass up "hey, a lot of my users are hitting this bug in [most recent release] which was fixed on [some date after the release]... Could you perhaps roll a new release so my users stop complaining?". That would be extremely resaonable. But just filing a bug report because a fixed bug wasn't already in a release is not reasonable for a package maintainer. Nor is doing so without at least a few simple checks to see if the bug has been fixed. I'll cut you some slack here, being new to the process. You haven't been around long enough to see all the bugs that have been fixed since 1.8.9. And indeed this particular patch was submitted via email and not via bugzilla. But it behooves ALL of us to localize the bug and not duplicate work and effort. The more time we have to spend closing out bug reports as "already been fixed", the less time we have to actually fix the real ones. -derek PS: Thank you for volunteering as the new debian maintainer. But you'll see that we still have over 400 open bugs and RFEs. :) -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
