Re: 2.3.1; traveling; request for bug help

[Owen Taylor <otaylor redhat com>]

OK, went through these. Milestones suggestions are completely my
opinion, since you are the maintainer :-)

There are a handful of --- milestoned bugs that need to be looked
at as well.

Thanks,
					Owen

On Sat, 2003-11-15 at 19:30, Matthias Clasen wrote:

> +p 112412 Corrections done by correct_total seem excessive when using
>    needs someone with an understanding of Owens "filter math" paper to
>    verify my conclusions

[2.4.1]

> ?  105859 Gtk+ image corruption on Linux Alpha
>    needs someone with a 64bit system to debug 

Can't reproduce on x86_64 (remote displayed). [2.4.1]

> ?  124496 Bad handling of --with-included-loaders in Gtk+ 2.2.4
>    needs Makefile hacking; doesn't look hard

[2.4.0]

> -  125232 GTK+ compile fails on gdk-pixbuf-csource on HP-UX w/ ANSI-C
>    needs to be debugged on HP-UX

[2.4.1]

> 2.4 API freeze
> ==============
> 
> - 74291 Feature request: gdk_pixbuf_new_from_raw_data ()
>   simple, but not very important

Don't think new_from_memory() would hurt, but definitely not a
blocker for 2.4. [2.6 API Freeze]

> - 95865 gdk_pixbuf_rotate_simple
>   simple, but not very important

[2.6 API Freeze]

> 2.4
> ===
> 
> +p 111922 scaling functions have bugs
>    patch needs some more work

Would be nice to get in, but someone needs to debug what's going wrong
as per Brian's comments. [2.4.0] 

> +  107398 One too many frame updates for GIF animations?
>    needs a test case, then the fix will be trivial

Creating a test GIF should be trivial - just create a two frame
GIF animation in the GIMP that doesn't loop. A test C program
should be pretty easy to do by modifying testanimation.c.
But it's just cosmetic. [2.4.1]

> ?p 90621 patch for integer pixops
>    kind of depends on the accuracy guarantees that need to be defined
>    for 77248/77249, to figure out if a fixed point implementation is 
>    acceptable.

[2.6.0]

> ?p 101628 [patch] JBig pixbuf loader
>    needs a policy decision: since the introduction of
> gdk-pixbuf-query-loaders,
>    we've had some success with bundling pixbuf loaders with the 
>    image library they depend on, therefore I'd be reluctant to 
>    introduce new dependencies on non-standard image libs into
>    gdk-pixbuf. If bundling this with jbigkit isn't an option, then 
>    maybe we should think about an umbrella project for 3rd party 
>    pixbuf loaders, similar to gtk-im-extra.sourceforge.net.

I don't want any more dependencies in the core of GTK+. Plus 
jbig-kit is GPL and has possible patent issues. 

(Whether GPL-licensed loaders can be loaded into non-GPL
apps is an issue I'd rather avoid for the main GTK+ 
distribution.)

[WONTFIX]

> -  50187 Robustness audit on pixbuf loader modules
>    the loaders should be pretty robust now, since Soerens 
>    random data tests have allowed us to plug many holes.
>    Owens final comment in the bug is "the remaining project here 
>    (developing a standard for a formal audit and doing it) is a 
>    rather large job."

Certainly a punt for 2.4.0. Probably need to put out a public call
for volunteers on this. [2.6.0]

> -  77248 mmx / tile scaling bug
>    no patch, hard to fix, needs figuring out the accuracy guarantees
>    we want would be the first step before trying to get the MMX 
>    code working in more cases.

[2.4.1]

> -  77249 rounding in pixops
>    seems more or less a duplicate of 77248; the fix here would be
>    a spec for the desired rounding behaviour

Difference is 77248 is specifically about the MMX code. [2.4.1]

> -  80927 Special-case compositing/copying with no scaling
>    no patch, a lot of work

Well, not *that* much work. But definitely [2.6.0]

> -  60842 configure/compile error. Line too long when generating gtk/s
>    what we have now works, if it isn't elegant

[WONTFIX], IMO.