[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    release readiness
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2011-11-24 9:31:47
Message-ID: 201111241031.47524.boud () valdyas ! org
[Download RAW message or body]

We've just released the 4th beta, so it's time to check the current state of Krita. \
We've made some good progress, but I'm not entirely elated, to be honest... We're far \
from an excellent release yet.

=== Unit tests ===

From zero failing unittests, we're back at five!

         80 - krita-image-KisCloneLayerTest (Failed)
        103 - krita-image-KisWalkersTest (Failed)
        104 - krita-image-KisAsyncMergerTest (Failed)
        144 - krita-image-KisActionRecorderTest (Failed)
        145 - krita-image-KisProcessingsTest (Failed)

As long as these tests fail, we simply cannot release!

=== Critical bugs and crashes ===

We have 3 critical bugs left:

285441 srikanth.tulasiram@gmail.com Downloading presets from GHNS does no longer work
262324 lukast.dev@gmail.com krita produces artefacts when upscaling
217292 boud@valdyas.org Ability to paint transparency masks 

2 grave bugs, 4 major bugs, 31 crashes and a grand total of 111 bugs. Functionality \
that is currently completely broken or seems unusably broken to the user is:

* GHNS integration
* Preset creation (previews are broken, saving presets with a name of a preset that \
                was deleted earlier on)
* Working with masks

I also found memcheck errors in the jpg filter that worry me a lot: \
https://bugs.kde.org/show_bug.cgi?id=287401

=== Memory leaks ===

Tobias Hagberg reported a memory leak bug. He worked with 2.3, but it turns that \
wether his leak is the same as our leak, we do have a leak in git master. Check the \
attached PNG image. It shows the memory consumption of Krita over time. What I did \
was load an image, convert it to cmyk, save it as tiff, close the image (but not \
krita), rinse and repeat. The dark red bottom band is tile data. You can see that we \
do release memory when closing an image, but not nearly all of it! And in fact, when \
we close the image for the second time, some memory is released, but again, not all, \
until the application quits. 

See bug https://bugs.kde.org/show_bug.cgi?id=287344 for massif logs, the output of \
our own memory checker and more details.

I am strongly minded to classify this bug as critical. It ties in with some of the \
crashes Silvio Grosso reported, since those are also about memory leaks and I am \
certain that this is a regression.

-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl


["massif.png" (image/png)]

_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


[prev in list] [next in list] [prev in thread] [next in thread]