[Kst] Tag and branch

Barth Netterfield netterfield at astro.utoronto.ca
Tue Nov 23 02:09:16 CET 2004

On Monday 22 November 2004 19:49, George Staikos wrote:
> Barth, if you can get your patches into CVS I will try to completely branch
> CVS tonight.  

I think they are in now.

> We'll have a stable branch and a HEAD branch, and 1.0 will be 
> released from the stable branch.  That means if we do any bugfixes over the
> next 24 hours, they have to go into both branches.  HEAD remains -frozen-
> until Wednesday at the earliest.

> Tomorrow I will tag 1.0 and create packages, probably somewhere around 3 or
> 4 pm.  We can do any testing in the early evening and I can upload it to
> the FTP server after it looks OK.

I just did cvs2dist here and we are installing on a couple BLAST machines to 
test.  Both realtime work, and some data analysis work from ascii.

> Before I unfreeze HEAD (I'll send a note to the list), I'd like to merge
> the HFI fixes.  Are there any in there that anyone objects to?  (You saw
> the commit logs...)

Seemed ok.

> I also need to discuss with the i18n team on how to arrange i18n issues
> with two branches since they're only "capable" of dealing with KDE-specific
> tags and branches.

What does this mean?

> Finally, when we unfreeze, I would like to propose that we actually not do
> new development for a week or two, just bug fixing, and more importantly,
> developing a testing framework and implementation.  Included in this would
> be some reworking of compilation structure of Kst to facilitate this, and
> facilitate the building of a Kst library for other C++ apps.  The equation
> testing tool is phenomenally powerful, and I think it shows that we: a)
> really need this in other areas (PSDs, plotting code, histograms, plugins,
> UI, labels, and more)
> b) have many undiscovered bugs that don't hit our own common usage cases
> c) have no way to systematically detect regressions
> We need a test suite, and I don't see us doing it unless we force ourselves
> to work on it.  It's more important to stabilizing Kst than bugfixing, in
> my opinion.

Given that we are going into doing math in production environments, I 
reluctantly agree.  I don't have any experience in writing such things, 
however.  I think we need a plan of attack, with some tasks we can all work 

> I read Barth's vision document and it looks great.  We should perhaps try
> to set it to a schedule.

Any one else have comments on it?

More information about the Kst mailing list