Steve Langasek <[EMAIL PROTECTED]> writes: > > It seems to me that if a package is in NEW in order to fix a bug in > > testing (especially an important or higher severity bug), then we > > shouldn't freeze until the bug fix has propogated throught NEW > > processing. > > Generally, yes. I don't actually see anything in the gnucash bts page that > explains why this would be a bug of important or higher severity, even > though you filed the bug on gtkhtml at severity: important requesting the > new upstream version.
It's been "important" since before I got the package, so the gtkhtml bug report was filed at the same severity because it was blocking an "important" bug. If you look at #190118, the original submitter marked it important, presumably because it prevents him from correctly printing invoices, leaving off his address and such. If you are using gnucash for a business, I would count this as a major effect on usability. At least, it's plausible, so I wasn't interested in trying to override the submitter's description of the severity. (In general, my approach is to leave submitter's severities alone unless I know they are wrong; whether something is a "major effect" depends on the user's particular situation and it's worth taking that into account.) > I'd be much more enthusiastic if something was in the works that would drop > gnucash's dependency on the ancient and decrepit gal package, which has > grown FTBFS several times over the past two years (and has another one right > now). There is: the gnome-2 gnucash. Upstream maintenance of this sort on the gnome-1 branch doesn't do anything for the gnome-2 branch but delay it. I'd be happy to take over maintenance of gal if Takuo wants me to. There are lots of packages that depend on it at present; gnucash is hardly the only one, is it? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
