0.6.0-rc1 available

[Ben Pfaff]

I put a pspp-0.6.0-rc1.tar.gz on alpha.gnu.org in /gnu/pspp.
This one untars to pspp-0.6.0 and identifies itself as PSPP
0.6.0.  It passes "make distcheck" here.  If you don't see
anything too wrong with it, then I'm inclined to upload it to
ftp.gnu.org as PSPP 0.6.0.

Please let me know what you think.

After the release, I want to try to get out bug-fix releases, at
least, on a more frequent basis than we've been doing.  Let's see
how that goes.
--
"If a person keeps faithfully busy each hour of the working day, he
 can count on waking up some morning to find himself one of the
 competent ones of his generation."
--William James


_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[John Darrington]

On Wed, Jun 04, 2008 at 09:53:13PM -0700, Ben Pfaff wrote:
     I put a pspp-0.6.0-rc1.tar.gz on alpha.gnu.org in /gnu/pspp.
     This one untars to pspp-0.6.0 and identifies itself as PSPP
     0.6.0.  It passes "make distcheck" here.  If you don't see
     anything too wrong with it, then I'm inclined to upload it to
     ftp.gnu.org as PSPP 0.6.0.
     
     Please let me know what you think.

Well let's not forget to attend to bugs  #20825 and  #20824 before we
do that final upload.

J'

--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.




_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[Ben Pfaff]

John Darrington <john@...> writes:

> On Wed, Jun 04, 2008 at 09:53:13PM -0700, Ben Pfaff wrote:
>      I put a pspp-0.6.0-rc1.tar.gz on alpha.gnu.org in /gnu/pspp.
>      This one untars to pspp-0.6.0 and identifies itself as PSPP
>      0.6.0.  It passes "make distcheck" here.  If you don't see
>      anything too wrong with it, then I'm inclined to upload it to
>      ftp.gnu.org as PSPP 0.6.0.
>      
>      Please let me know what you think.
>
> Well let's not forget to attend to bugs  #20825 and  #20824 before we
> do that final upload.

#20825 is "The AUTHORS file needs updating before the next
release," but I am not sure what changes should be made.  What do
you suggest?

#20824 is "Update the text in the About dialog before the next
release," but the text in the About dialog is partially generated
from the AUTHORS file, so fixing #20825 could possibly also fix
this.  I do not know whether other changes are needed.
--
"Mon peu de succès près des femmes est toujours venu de les trop aimer."
--Jean-Jacques Rousseau


_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[John Darrington]

On Thu, Jun 05, 2008 at 05:47:21AM -0700, Ben Pfaff wrote:
     John Darrington <john@...> writes:
     
     > On Wed, Jun 04, 2008 at 09:53:13PM -0700, Ben Pfaff wrote:
     >      I put a pspp-0.6.0-rc1.tar.gz on alpha.gnu.org in /gnu/pspp.
     >      This one untars to pspp-0.6.0 and identifies itself as PSPP
     >      0.6.0.  It passes "make distcheck" here.  If you don't see
     >      anything too wrong with it, then I'm inclined to upload it to
     >      ftp.gnu.org as PSPP 0.6.0.
     >      
     >      Please let me know what you think.
     >
     > Well let's not forget to attend to bugs  #20825 and  #20824 before we
     > do that final upload.
     
     #20825 is "The AUTHORS file needs updating before the next
     release," but I am not sure what changes should be made.  What do
     you suggest?

I suggest that we apply this patch:

Index: AUTHORS
===================================================================
RCS file: /sources/pspp/pspp/AUTHORS,v
retrieving revision 1.7
diff -b -w -U 3 -r1.7 AUTHORS
--- AUTHORS     24 Dec 2006 06:57:54 -0000      1.7
+++ AUTHORS     6 Jun 2008 00:16:06 -0000
@@ -1,16 +1,18 @@
 We wish to thank current active contributors to PSPP:
 
 * Ben Pfaff wrote the initial program and manual, which comprises the
-majority of the current code.  Ben is the current maintainer and
-continues to contribute.
+majority of the current code. Ben continues to contribute and
+most of the core libraries which ensure that PSPP runs with optimal
+speed are his work.
 
 * John Darrington wrote the graphical user interface, and the T-TEST,
 ONEWAY, EXAMINE, RANK and  NPAR TESTS commands, implemented support
-for long variable names and made numerous revisions to other
 modules.  
+for long variable names, psql and gnumeric and made numerous
+revisions to other  modules.  
 
 * Jason Stover contributed statistical and numerical functionality,
-including lib/gslextras. Jason is also an important contributor to
-GSL, used by PSPP.
+including lib/gslextras and the linear regression features. Jason
+is also an important contributor to GSL, which is used by PSPP.
 
 We also thank past contributors:
 


     
     #20824 is "Update the text in the About dialog before the next
     release," but the text in the About dialog is partially generated
     from the AUTHORS file, so fixing #20825 could possibly also fix
     this.  I do not know whether other changes are needed.

As we've now done some fairly extensive testing, I think that we
should change the text "This is pre-alpha software. Use at your own
risk." to something more optimistic.

J'

--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.




_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[Ben Pfaff]

John Darrington <john@...> writes:

> On Thu, Jun 05, 2008 at 05:47:21AM -0700, Ben Pfaff wrote:
>      John Darrington <john@...> writes:
>      
>      > On Wed, Jun 04, 2008 at 09:53:13PM -0700, Ben Pfaff wrote:
>      >      I put a pspp-0.6.0-rc1.tar.gz on alpha.gnu.org in /gnu/pspp.
>      >      This one untars to pspp-0.6.0 and identifies itself as PSPP
>      >      0.6.0.  It passes "make distcheck" here.  If you don't see
>      >      anything too wrong with it, then I'm inclined to upload it to
>      >      ftp.gnu.org as PSPP 0.6.0.
>      >      
>      >      Please let me know what you think.
>      >
>      > Well let's not forget to attend to bugs  #20825 and  #20824 before we
>      > do that final upload.
>      
>      #20825 is "The AUTHORS file needs updating before the next
>      release," but I am not sure what changes should be made.  What do
>      you suggest?
>
> I suggest that we apply this patch:

[...]
> +revisions to other  modules.  
[...]

There's an extra space in there.

>      #20824 is "Update the text in the About dialog before the next
>      release," but the text in the About dialog is partially generated
>      from the AUTHORS file, so fixing #20825 could possibly also fix
>      this.  I do not know whether other changes are needed.
>
> As we've now done some fairly extensive testing, I think that we
> should change the text "This is pre-alpha software. Use at your own
> risk." to something more optimistic.

[...]

Both of these changes sound good to me.  Unless Jason has
comments, please feel free to check in these changes.
--
"Premature optimization is the root of all evil."
--D. E. Knuth, "Structured Programming with go to Statements"


_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[John Darrington]

On Wed, Jun 04, 2008 at 09:53:13PM -0700, Ben Pfaff wrote:
     After the release, I want to try to get out bug-fix releases, at
     least, on a more frequent basis than we've been doing.  Let's see
     how that goes.

I suggest that we maintain three branches.

1. A branch containing the current release patched with  bug-fixes.

2. A branch containing 1 (above) patched with enhancements.
   "Enhancements" in this context means changes which provide new
   functionality without requiring major code reorganisation.  Eg new
   commands which don't require low level library modification.

3. A branch containing 2. patched with any changes which don't fit
   the above criteria.


J'



--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.




_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[Ben Pfaff]

John Darrington <john@...> writes:

> On Wed, Jun 04, 2008 at 09:53:13PM -0700, Ben Pfaff wrote:
>      After the release, I want to try to get out bug-fix releases, at
>      least, on a more frequent basis than we've been doing.  Let's see
>      how that goes.
>
> I suggest that we maintain three branches.
>
> 1. A branch containing the current release patched with  bug-fixes.
>
> 2. A branch containing 1 (above) patched with enhancements.
>    "Enhancements" in this context means changes which provide new
>    functionality without requiring major code reorganisation.  Eg new
>    commands which don't require low level library modification.
>
> 3. A branch containing 2. patched with any changes which don't fit
>    the above criteria.

Is there some existing project that uses a similar scheme?  I am
familiar with projects that have a bug fix-only branch and a
development branch, but I am a little concerned that maintaining
both #2 and #3 could cause a lot of extra work.
--
Ben Pfaff
http://benpfaff.org


_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[Jason Stover-3]

On Thu, Jun 05, 2008 at 06:43:18PM -0700, Ben Pfaff wrote:
> Both of these changes sound good to me.  Unless Jason has
> comments, please feel free to check in these changes.

Sounds OK to me.

-Jason


_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[Jason Stover-3]

On Wed, Jun 04, 2008 at 09:53:13PM -0700, Ben Pfaff wrote:
> I put a pspp-0.6.0-rc1.tar.gz on alpha.gnu.org in /gnu/pspp.
> This one untars to pspp-0.6.0 and identifies itself as PSPP
> 0.6.0.  It passes "make distcheck" here.  If you don't see
> anything too wrong with it, then I'm inclined to upload it to
> ftp.gnu.org as PSPP 0.6.0.

I ran tests on 4 different systems. The summaries are below.  I don't
suggest fixing these before the release, since we have gone back and
forth with them and haven't found a way to fix them once and for
all. They are bugs in the tests, not the output, and tweaking them is
holding up development on the GLM procedure and lib/linreg and maybe
some other things too. Plus, Ben's output system should enable
breaking the tests into those for output, and those for formatting
output, rather than just diffing text (I hope that last part is right,
anyway).

GNU/Linux + x86: all tests passed
------------------------------------

OpenBSD + x86: The following tests failed:

1. tests/formats/format-guesser.sh
2. tests/bugs/signals.sh
3. tests/stats/moments.sh
4. tests/expressions/expressions.sh
5. tests/expressions/epoch.sh

Output for these tests is below:

0a1,2
> Warning: cannot create a convertor for "646" to "UTF-8": Invalid argument
> Warning: cannot create a convertor for "UTF-8" to "646": Invalid argument
compare output
FAILED
FAIL: tests/formats/format-guesser.sh

checking for absence of error messages 1
FAILED
FAIL: tests/bugs/signals.sh

0a1,2
> Warning: cannot create a convertor for "646" to "UTF-8": Invalid argument
> Warning: cannot create a convertor for "UTF-8" to "646": Invalid argument
compare two-pass output
FAILED
FAIL: tests/stats/moments.sh

0a1,2
> Warning: cannot create a convertor for "646" to "UTF-8": Invalid argument
> Warning: cannot create a convertor for "UTF-8" to "646": Invalid argument
compare optimizing output
FAILED
FAIL: tests/expressions/expressions.sh
1,2d0
< Warning: cannot create a convertor for "646" to "UTF-8": Invalid argument
< Warning: cannot create a convertor for "UTF-8" to "646": Invalid argument
compare results
NO RESULT
FAIL: tests/expressions/epoch.sh
------------------------------------

Sparc + Solaris "10": 2 failures:

1. tests/bugs/signals.sh
2. tests/bugs/overwrite-input-file.sh
-------------------------------------

NetBSD + alpha: 2 failures:

1. tests/bugs/overwrite-input-file.sh
2. tests/bugs/signals.sh

>
> Please let me know what you think.
>
> After the release, I want to try to get out bug-fix releases, at
> least, on a more frequent basis than we've been doing.  Let's see
> how that goes.
> --
> "If a person keeps faithfully busy each hour of the working day, he
>  can count on waking up some morning to find himself one of the
>  competent ones of his generation."
> --William James
>
>
> _______________________________________________
> pspp-dev mailing list
> pspp-dev@...
> http://lists.gnu.org/mailman/listinfo/pspp-dev

_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[John Darrington]

On Fri, Jun 06, 2008 at 09:39:04AM -0700, Ben Pfaff wrote:
     John Darrington <john@...> writes:
     
     > On Wed, Jun 04, 2008 at 09:53:13PM -0700, Ben Pfaff wrote:
     >      After the release, I want to try to get out bug-fix releases, at
     >      least, on a more frequent basis than we've been doing.  Let's see
     >      how that goes.
     >
     > I suggest that we maintain three branches.
     >
     > 1. A branch containing the current release patched with  bug-fixes.
     >
     > 2. A branch containing 1 (above) patched with enhancements.
     >    "Enhancements" in this context means changes which provide new
     >    functionality without requiring major code reorganisation.  Eg new
     >    commands which don't require low level library modification.
     >
     > 3. A branch containing 2. patched with any changes which don't fit
     >    the above criteria.
     
     Is there some existing project that uses a similar scheme?  I am
     familiar with projects that have a bug fix-only branch and a
     development branch, but I am a little concerned that maintaining
     both #2 and #3 could cause a lot of extra work.


Well Debian uses a very similar system:

1. The current release.

2. The current release + fixes for security related bugs.

3. The current release + fixes for security related bugs + other
   changes.


Obviously, more branches means more work.  How much extra work depends
on how much the branches overlap, how often they're merged and how
well git has been designed to handle branches.

J'




--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.




_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[John Darrington]

On Wed, Jun 04, 2008 at 09:53:13PM -0700, Ben Pfaff wrote:
     I put a pspp-0.6.0-rc1.tar.gz on alpha.gnu.org in /gnu/pspp.
     This one untars to pspp-0.6.0 and identifies itself as PSPP
     0.6.0.  It passes "make distcheck" here.  If you don't see
     anything too wrong with it, then I'm inclined to upload it to
     ftp.gnu.org as PSPP 0.6.0.

On GNU/Hurd I get one test failure:

./tests/libpspp/abt-test

.Check failed in insert any order, delete any order test at ../SRC/pspp-0.6.0/tests/libpspp/abt-test.c, line 360

:(


_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[Ben Pfaff]

John Darrington <john@...> writes:

> On GNU/Hurd I get one test failure:
>
> ./tests/libpspp/abt-test
>
> .Check failed in insert any order, delete any order test at ../SRC/pspp-0.6.0/tests/libpspp/abt-test.c, line 360

If you pass along a backtrace, perhaps I can fix it.  But if I
can't, then it seems like a pretty low priority.
--
"The sound of peacocks being shredded can't possibly be
 any worse than the sound of peacocks not being shredded."
Tanuki the Raccoon-dog in the Monastery


_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[Ben Pfaff]

John Darrington <john@...> writes:

> On Fri, Jun 06, 2008 at 09:39:04AM -0700, Ben Pfaff wrote:
>      John Darrington <john@...> writes:
>      
>      > On Wed, Jun 04, 2008 at 09:53:13PM -0700, Ben Pfaff wrote:
>      >      After the release, I want to try to get out bug-fix releases, at
>      >      least, on a more frequent basis than we've been doing.  Let's see
>      >      how that goes.
>      >
>      > I suggest that we maintain three branches.
>      >
>      > 1. A branch containing the current release patched with  bug-fixes.
>      >
>      > 2. A branch containing 1 (above) patched with enhancements.
>      >    "Enhancements" in this context means changes which provide new
>      >    functionality without requiring major code reorganisation.  Eg new
>      >    commands which don't require low level library modification.
>      >
>      > 3. A branch containing 2. patched with any changes which don't fit
>      >    the above criteria.
>      
>      Is there some existing project that uses a similar scheme?  I am
>      familiar with projects that have a bug fix-only branch and a
>      development branch, but I am a little concerned that maintaining
>      both #2 and #3 could cause a lot of extra work.
>
> Well Debian uses a very similar system:
>
> 1. The current release.
>
> 2. The current release + fixes for security related bugs.
>
> 3. The current release + fixes for security related bugs + other
>    changes.

Debian's stable (#1 above) and security fix (#2 above)
distributions, taken together, are equivalent to the proposed
PSPP branch #1 above.  The changes between #1 and #2 are normally
very small, because Debian generally applies the minimal change
necessary to fix a security bug.

Debian's unstable distribution (#3 above, roughly) is somewhat
akin to the proposed PSPP branch #3 above: most packages in it
contain the newest release upstream version of software
(sometimes even unreleased versions from VCS).

I don't see anything equivalent to proposed PSPP branch #2.
That's the one that worries me.

> Obviously, more branches means more work.  How much extra work depends
> on how much the branches overlap, how often they're merged and how
> well git has been designed to handle branches.

I don't see how branches in this scheme could ever merge.  Many
changes that are appropriate for #2 will never be appropriate for
#1, and similarly many changes that are appropriate for #3 will
never be appropriate for #2 or #3.

I'm not worried about Git handling branching and merging.  It
does both well.

Here is the branching model that I was envisioning maintaining at
Savannah:

        - A bug fix branch for whatever is the current released
          version.

        - An active development branch that contains whatever is
          targeted to appear in the next released version of
          PSPP.

        - Additional experimental branches as necessary for
          public and possibly collaborative long-term development
          of big features that aren't ready for the active
          development branch yet, one per feature.  For example,
          I'm assuming that the new output subsystem will be
          developed this way.  Eventually these branches get
          merged back into the active development branch, if the
          experiment is successful, and then discarded (although
          the Git history shows that the branch was merged and
          retains the branch history; that is, no information is
          lost).

Maybe my vision for as-needed experimental branches is really the
same as your proposed branch #3?

In addition, I'll probably have half a dozen or so branches in
various stages of development going locally on my development
machine at any given time.  Over at Nicira, I've probably had as
many as a dozen.  Git makes it trivial to create, merge, and
discard branches, so it's my habit to use one per feature that
I'm working on.  It appears that many Git users work this way.
--
"Long noun chains don't automatically imply security."
--Bruce Schneier


_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[John Darrington]

On Fri, Jun 06, 2008 at 09:38:18PM -0700, Ben Pfaff wrote:
     John Darrington <john@...> writes:
     
     > On GNU/Hurd I get one test failure:
     >
     > ./tests/libpspp/abt-test
     >
     > .Check failed in insert any order, delete any order test at ../SRC/pspp-0.6.0/tests/libpspp/abt-test.c, line 360
     
     If you pass along a backtrace, perhaps I can fix it.

I don't think I shall be able to, at least not in the next few days.
My attempts to install gdb resulted in a system which won't boot :(

J'

--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.




_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[Ben Pfaff]

Ben Pfaff <blp@...> writes:

> I put a pspp-0.6.0-rc1.tar.gz on alpha.gnu.org in /gnu/pspp.
> This one untars to pspp-0.6.0 and identifies itself as PSPP
> 0.6.0.  It passes "make distcheck" here.  If you don't see
> anything too wrong with it, then I'm inclined to upload it to
> ftp.gnu.org as PSPP 0.6.0.

Now there's a pspp-0.6.0-rc2.tar.gz.  The only changes from -rc1
should be in AUTHORS and the PSPPIRE about dialog.  Oh, and I
changed the wording of one of the release notes to mention that
OSes other than OpenBSD could produce locale errors at "make
check" time.

Same deal: if you see any problems, let me know.  Otherwise, this
will be PSPP 0.6.0 pretty soon.

Thanks everyone!
--
"I admire him, I frankly confess it; and when his time comes
 I shall buy a piece of the rope for a keepsake."
--Mark Twain


_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[Ben Pfaff]

Ben Pfaff <blp@...> writes:

> John Darrington <john@...> writes:
>
>> On Fri, Jun 06, 2008 at 09:39:04AM -0700, Ben Pfaff wrote:
>>      John Darrington <john@...> writes:
>>      > I suggest that we maintain three branches.
>>      >
>>      > 1. A branch containing the current release patched with  bug-fixes.
>>      >
>>      > 2. A branch containing 1 (above) patched with enhancements.
>>      >    "Enhancements" in this context means changes which provide new
>>      >    functionality without requiring major code reorganisation.  Eg new
>>      >    commands which don't require low level library modification.
>>      >
>>      > 3. A branch containing 2. patched with any changes which don't fit
>>      >    the above criteria.
>>
>> Obviously, more branches means more work.  How much extra work depends
>> on how much the branches overlap, how often they're merged and how
>> well git has been designed to handle branches.
>
> I don't see how branches in this scheme could ever merge.  Many
> changes that are appropriate for #2 will never be appropriate for
> #1, and similarly many changes that are appropriate for #3 will
> never be appropriate for #2 or #3.

Upon reflection, I think you must have meant merging in the other
direction: fixes from #1 merged into #2 and #3, and enhancements
from #2 merged into #3.  That makes sense.
--
"The fact is, technical people are better off not looking at patents. If
 you don't know what they cover and where they are, you won't be knowingly
 infringing on them. If somebody sues you, you change the algorithm or you
 just hire a hit-man to whack the stupid git." --Linus Torvalds


_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[John Darrington]

On Mon, Jun 09, 2008 at 09:05:10AM -0700, Ben Pfaff wrote:
     
     Upon reflection, I think you must have meant merging in the other
     direction: fixes from #1 merged into #2 and #3, and enhancements
     from #2 merged into #3.  That makes sense.

???  Surely merging is a commutative operation?  One starts with two
streams of development and end up with only one which is the union of
the first two. A \cup B \equiv B \cup A  I don't see that it makes any
sense to talk about the direction in which one merges.

J'

--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.




_______________________________________________
pspp-dev mailing list