[Kst] Architectural changes

[Matthew D Truch]

> So:  From now to 2.0, we should work only on critical bug fixes and critical 
> or very easy feature fixes, which a goal of a 2.0 release on the weekend of 
> January 1.
> 
> The exception to this would be if we find a reason we would need to do an API 
> change to data-sources or plugins, in which case the Jan 1 release would be 
> called '2.0-beta4'
> 
> Thoughts?

I am also in Nicholas' boat as I'm not a real programer and I don't even
play one on TV, so my comments are more on schedule and polish.  

What do you define as "critical".  Are you talking about bugs that crash
kst or make it otherwise not work, or also things like performance
issues that make it not work for certain BLAST-y amounts of live data?

Doesn't January 1st seem like a poor date for release from a QA/testing
point of view.  I would recommend at a week long (or at least a couple
days) testing period to check for bugs/issues that may have crept in.
This window needs to be when people are likely to be able to test it
(aka not on vacation).  Of course, if you're willing to release 2.0.1 by
the middle of January for such fixes, then maybe this is ok (I'm a big
fan of "release early, release often").  

-- 
"Party on Wayne; Party on Garth. -- Wayne's World"
--------------------------
Matthew Truch
Department of Physics and Astronomy
University of Pennsylvania
matt at truch.net
http://matt.truch.net/
-------------- 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/kst/attachments/20091210/24f9d753/attachment.sig