releasing inplications

[Boudewijn Rempt]

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 
away...)

> 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.


-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050313/ba198c5a/attachment.pgp