Kst going forward

   Last week Barth, Andrew, Rick and myself had a meeting to discuss the 
future of Kst, in particular with respect to collaboration and procedures.  
Kst has been Barth's project for many years now, but he has a very busy 
schedule and doesn't have the time to oversee development anymore.  This 
leaves a big void in Kst development.  Barth traditionally made the final 
call for technical decisions, development policy, and anything else regarding 
Kst development and direction.  In other words, he was the maintainer.

   In his absence, Barth has asked me to take over this role, and has asked 
that we continue to work together in an open manner on Kst.  That is to say, 
design and decisions about Kst should be discussed on the Kst mailing list 
(and bug tracking system) and design documents should be developed and 
followed.  However, when faced with disagreement that cannot be resolved, I 
will be responsible for making the final (and correct) decision.  Hopefully 
it will rarely come to this.

  As far as how we collaborate, we need to be more communicative and we need 
to follow the guidelines that have existed since Kst was imported into the 
KDE CVS repository.  In the meeting, it was agreed upon to try interacting on 
major feature designs via the bug tracking system and keeping copies of the 
information in the devel-docs directory in SVN.  This is important because 
bugzilla is an on-line tool, while development does not always happen 
on-line.  If a new feature is requested, it cannot be hacked into the 
repository simply because a developer has access.  It needs to be discussed 
and not only the feature design, but also the implementation approach need to 
be approved.  Kst development is not an ad-hoc procedure.

  I am the release coordinator, and I will continue to maintain the release 
plan, ideally with bug numbers on each line item as well as names of 
developers working on the items.  The 1.2 release features have been 
documented and the release date is now scheduled for October 2005, with 1.3 
following in the late winter/early spring 2006.  Intermediate releases 
(1.1.1, etc) will be made and bug fixes should be committed atomically and 
without unnecessary changes so that they can be backported.  Just send me the 
bug number and patch, CCMAIL me on the commit, or find some other way to 
communicate to me that a patch applies to the branch and I will merge it.

  I will also aim to do a development release of Kst 1.2 in August if the code 
is stable and the new features are complete enough for users to demonstrate 
and test.

  If any developer wishes to do work that does not align with the current 
focus of the Kst release or the Kst development procedures, that developer is 
welcome to create a branch in SVN for it, but must not interfere with trunk.

  It is important to keep in mind that Kst is much more than just a tool for 
Planck.  It started out as software for other research projects, it is 
scheduled for use in future research projects, and is now in use by many 
other individual users, companies, and institutions.  Kst has to be designed 
with the future in mind, including maintenance, potential new use cases and 
requirements, and portability - including to KDE 4.

  In order to keep the code clean, when I first started on Kst, Barth and I 
agreed to a certain formatting scheme in order to keep the code uniform and 
easy to work with.  This was basically me agreeing to Barth's favorites and 
documenting them.  We need to preserve this in order to preserve SVN 
annotations and make patches easy to read.  The documentation may not be 
complete, and it is certainly open for debate if someone doesn't agree with 
something in there.  However, please do not use different formatting in 
protest.  If you feel so strongly about something that you insist on doing 
it, please start a thread on the mailing list.  Furthermore, I am willing to 
write modelines for vim, emacs, and kate if anyone needs these made in order 
to keep proper formatting.

  (Don't forget, in .ui.h files, we use Designer style indenting!)

  Code review is also a major part of the open source development model, the 
KDE development model, and our ongoing Kst development model.  Do not be 
offended if your commits are read and commented on.  Simply address the 
comments as appropriate and move on.  Also, join the process and review the 
commits by others.  It's a proven means of ensuring quality control in a 
process that has no formal quality control procedures.

  There is a testcase directory in SVN which really needs to be further 
developed.  If anyone is looking for something to do, please consider writing 
unit tests for critical Kst components.  Those testcases are great for 
catching regressions and really help keep Kst stable.  I even have them 
automated and can re-enable the script when the test coverage improves.  
Also, if you change any components that have testcases, the testcases need to 
be updated to reflect the new behaviour.  If anyone has questions about how 
the test system works, please send a note to the list and I'll help you out.

  The major new focal points for Kst at this time are matrix/image reworking, 
scripting, new label code, and graphics objects (including associated view 
object changes).  Design documents, bugs, and feature documents are generally 
available for all of these items, and we need to work together to make sure 
they're done effectively and efficiently.

  If we can move forward and work together under the same procedures and 
guidelines, we can really turn Kst into a killer science app.  Let's make 
this work!

-- 
George Staikos
KDE Developer                           http://www.kde.org/
Staikos Computing Services Inc.         http://www.staikos.net/