boud at valdyas.org
Sun Mar 13 16:04:09 CET 2005
On Sunday 13 March 2005 15:21, Casper Boemann wrote:
> Sure, and I wasn't saying that we shouldn't release. In fact I think we
> should release often.
> My qualm is the strictness off releasing as part of ko. They release to
> slowly for a developing application
It takes quite a lot of effort to set up a release regimen -- it's not just
that you need to do a regular source tarball, but you really need binary
releases for that to be effective. Maybe we should consult the Amarok hackers
because they do frequent releases. Of course, releasing apart from KOffice
would mean that we would have to stay compatible with the current stable
release of KOffice; that's extra effort too. Finally, the other KOffice
people have a say in this, and I don't know whether they would be agreeable
to a divorce.
Which is not to say that we cannot do frequent releases of our own, we just
need to find a formula for that. I want Krita to be a fully supported
application of KOffice 1.4 -- and I want a frequent binary release compatible
with KOffice 1.4 but containing the latest features. And whenever a new
KOffice version is released, I want to be part of that.
I've discussed this with Michael Thaler before, by the way. There's not all
that much code that actually ties us in to KOffice: the document/view
classes, the file store and a vestigial use of koPainter. Personally, I'm
really happy with the current way of handling files and for me the cutoff
point would be where KOffice drops support for koStore. If that happens, we
need to go our own way.
Anyway, for now:
- Our first (1.0) release is with KOffice 1.4.
- I'm all for a really frequent release of Krita HEAD against the KOffice 1.4
libs after that.
Which is pretty much what you were arguing for too, I guess :-).
> Sure, but things like colorspace independence needs much fixing so almost
> the day after 1.0 we'd need to break the api. Just so that the users don't
> expect too much.
I'm not sure what needs fixing here -- it answers to its goal. I want to
extend KisChannel to allow all kinds of mathematical operations hiding the
underlying channel data type. But that's it -- I like the rest as it is.
Now what's a candidate for some work is the undo system. At the very least, we
need a way to stop the mementoing of paint device data. (Adding right
> Don't blaim the autolayer merge for everything. Many bugs existed
> beforehand. But sure it needed some work after the merge.
Sorry -- I didn't intend to be nasty. It's just that I hadn't expected to be
still working on the last bits of commented-out code in March :-(.
> I wasn't saying that bug report are bad, but if ko is only released once
> every half year, we would have moved a long way, and changed the
> application. So again if we could somehow release every month instead it
> would be much better.
True -- but those releases will never get the user base a regular release
gets, if only because KOffice is packaged with distributions that are
released at most twice a year and sometimes even less frequently. Once a
release gets into the wild world, we will be getting lots of bug reports that
we can close with "fixed in cvs".
> BUT, we need to fix colorspace independance before any more work is done on
> filters tools etc. At the moment we are darting out the wrong way, with
> much of the code needing to be refactored.
Hm... I know you want to add the math necessary for doing the channel-type
math into the color strategy class -- but have you got any other ideas? As
said above, I'd like to expand KisChannel and have people use that to do
their math, but if you do a writeup of the kind of design you propose I can
look at it.
As for plugins: I want to make even more things plugins. Docker tabs should be
plugins, too -- which makes some work on KisView necessary. I'd better do
that before the release, too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050313/ba198c5a/attachment.pgp
More information about the kimageshop