[Kopete-devel] Post 3.2 Kopete and packagers

[Martijn Klingens]

On Tuesday 25 November 2003 21:40, Jason Keirstead wrote:
> Being part of the release cycle is *better* for features. You get a longer
> time period to implement and test new features properly, and get proper
> planning of what features are needed via release schedules so you can
> properly focus your time.

Sure, we could (and probably should) have a release cycle for Kopete as well. 
Until now we didn't really have a release _cycle_, we just implemented stuff 
and when the new stuff was considered finished we began evaluating a new 
release. And while having a more formal Kopete release cycle is a good thing, 
how is it better to use the KDE release cycle rather than having our own at 
twice the rate? As long as you have a cycle in the first place it's ok.

> When we aren't using  the KDE release schedule things just turn into a huge
> mess. We're releasing every few months, which results in features getting
> rushed in and debugged on a part by part basis, instead of considering the
> product as a whole and doing them properly from the get-go, which is much
> easier when you have 8-10 months do design, develop, refactor, develop...
> (repeat as needed), instead of having to freeze the code every 8 weeks for
> another release.

Ehm, since when were features 'rushed in'? The only thing different this time 
compared to, say, 0.7 is the much longer freeze period of a couple of months 
rather than only roughly a month, but we still had a freeze and I don't think 
_anything_ was "rushed in". We could argue that a longer freeze is important, 
but that still is not an argument in favour of a yearly release as KDE does 
instead of 2-3 releases a year as we used to do.

> That paradigm is great for tacking on features like piecemeal, but it's no
> way to develop a properly design application. Over time you just end up
> with a huge mess.

Well, open source is not designed beforehand usually, hardly any OSS project 
follows the design rules you learn at school. It usually comes much closer to 
Extreme Programming.

And face it, designing beforehand only works if you know _exactly_ what you 
need to implement, with requirements study and all that. Kopete is way too 
dynamic for that, as is most open source software. It doesn't really work for 
most KDE apps. That doesn't mean one shouldn't design at all, it just means 
that design should be done on a smaller scale, and the design should be 
iteratively refactored after the initial implementation. I think even 
Konqueror and KMail still work this way.

> It seems like this is all this project does is hack stuff in.
> Mainly because there is not enough time between its over-frequent 
> releases to properly design, develop, re-adjust, redevelop, etc etc a
> feature to get it right the first time.

This is self-contradicting. If you get it right the first time you don't need 
to re-adjust and redevelop. If you need to re-adjust and redevelop you get 
EXACTLY what we have been doing until now. And so far I've seen libkopete 
slowly turn from a total mess into an API that's actually getting quite 
decent, so even though we still have about the same amount of work ahead 
before we can declare the API more or less stable I see little reason to 
complain.

PS: Reading the above I'm not sure if we should continue this discussion here. 
If anyone replies and it's not really on-topic for core-devel it might be 
better to move this off to kopete-devel instead. Even better of course would 
be to stop bitching about how bad we apparently have been doing and start 
coding instead, but I don't think I've got much of right to speak here until 
I can start some coding again halfway december.

-- 
Martijn