releasing inplications

[Boudewijn Rempt]

On Sunday 13 March 2005 13:27, Casper Boemann wrote:
> Hi all
>
> I have been thinking about our upcoming release. Do we really want to
> release.

Yes.

> On the plus side we have:
> - user awareness
> - bug reports
> - attracting developers

Those are not what I see as the big advantage of a release: having a release 
transforms an application from being a playground to something real. We need 
that, or, more accurately, _I_ need that. Krita has to stop being a promise 
and grow up. The only way is through exposure to the big bad world. We'll get 
a lot flak for sure, because after all these years we still don't have a 
16-bit/channel, cmm-enabled (okay, we've got that, but only rudimentary) Gimp 
killer with a side-order of real media painting. But if we don't do a 
release, we won't get there anyway.

> On the minus side we have:
> - half finished design that would undergo several changes in the next many
> releases, meaning fileformat and plugin changes. Backwards compatibillity
> would be an issue.

Not for me. It's silly to expect an application to retain it's 1.0 plugin API 
when you need a release just to discover what people need in such an API. And 
the file format should be pretty stable. I've got slight qualms about our 
usage for user-readable identifier strings for color models, profiles etc., 
but I've already got some code to factor that out. That should be included in 
the release. From that moment, we can just keep on extending the current file 
format (which is pretty good).

> - releasing a bugfilled application - is that a reputation we want

So, what we need to do is make a concerted effort to get the bugs out of the 
minimal featureset we want to support and forget everything else. We still 
have some fall-out from the autolayers merge; that must be repaired first. We 
haven't made the progress I had hoped, things appeared to be more broken than 
I thought -- wise lesson, never have an opinion on code you haven't worked 
with for a month, just eye-balling isn't enough -- and that has meant that 
some cool features couldn't be worked on.


> - bug reports that would be outdated almost before releasing

I'm pretty good at keeping bugzilla in order. Leave that to me, it's the 
application maintainer's job anyway.

> - having to spend time on bugfixes in a release version takes time away
> from developing.

We must get Krita more stable, even if it's only for our own developing 
pleasure. The current situation is really bad and detracts from my own 
development pleasure. A release will help with that.

> - attracting developers - the more we are the less consensus.

That's true... Maybe I should play the dictator more often :-). In any case, 
having too many developers would be an embarrasment of riches -- I wouldn't 
mind that, but I'm a natural born glutton. But once there's a release out, 
people can work on plugins. Almost everything can be a plugin: our tools are 
plugins, our color models are plugins, the filters are (of course) plugins 
and lots of the UI is encapsulated in plugins, too. New scaling/transforming 
code should be done as plugins, too, and most new UI inventions (palettes, 
other resources), too. Plugins are great because they parallellize 
development. 

> So for me the deciding point is what the KOffice team says about us
> releasing a "preview" as part of 1.4 without all the obligations of a true
> release.

That would be an option, but in practice, users would have a hard time 
perceiving the difference. A modest 1.0 release would be sufficient for me.

> Otherwise I would prefer a simultaneous release, but not a true part of KO.
>
> Another point is when the next ko release is scheduled.

David Faure has mailed a release schedule, and that's one I intend to follow. 
We have until April 11 to add features, until May 23 to fix bugs and until 
June 7 to fix critical bugs. We must release with KOffice 1.4. I for one 
would find it hard to sustain interest myself if we didn't.

-- 
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/9306ce87/attachment.pgp