Re: two gnucash bits
Steve Langasek <vorlon@debian.org> 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
Reply to: