Re: gnucash and etch freeze
On Tue, Feb 20, 2007 at 08:18:58PM -0800, Thomas Bushnell BSG wrote:
> One of the unfortunate side-effects of a freeze is that it becomes very
> hard to get necessary changes into etch when an upstream package is a
> more rapidly moving target.
> In the four months since gnucash 2.0.2 was released, much development
> has happened, and upstream has released several more versions. The
> general reliability of the program is much improved, with a thousand
> small annoyances and crashes fixed. I am told also that some of these
> fixes include security-related issues (most importantly, vulnerabilities
> through /tmp).
> Now I simply do not have the time to go through the changelog, pick out
> changes that I think should be in etch and do them.
> If the release team shrugs and says, well, ok, go ahead and upload the
> new version and we'll consider it as-is for etch, that would be great,
> but my understanding is that this is contrary to the release policy. Is
> my understanding correct?
Does the new upstream version fix the bug in 2.0.2 where it doesn't know the
right direction to apply interest payments on bank accounts? I could
probably be persuaded to spend quite a disproportionate amount of time
reviewing a gnucash update if it takes care of that for me.
Alternatively, I accept bribes in the form of RC bugfixes wrapped up with a
bow on top. (/Not/ in the same package, it doesn't exactly save the release
team any time in that case...)
Anyway, there's no hard and fast policy against new upstream versions being
allowed in during the freeze. The guidelines are those posted to d-d-a --
we want debdiffs to be small and free of extraneous changes so that they can
be quickly reviewed without spending a lot of time puzzling over the impact
of changes that aren't relevant in the first place to bugfixes that would
warrant a freeze exception.
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.