From: <lu...@gi...> - 2004-05-12 17:53:55
|
Hi John John Peterson writes: > It seems the toughest road-block to making a release > is that someone (read Ben) has to download and build > the library on N different platforms to make sure everything > is still hunky-dory everywhere. > > I would vote for a more active release schedule, say every > month or 2 weeks, where we just release what we have without the > exhaustive rebuild on every system. That way we let users > who are actually on those systems discover the bugs ;) and > report them, and then a new release is not far away. +1 > If everyone agrees, then I suggest Ben and I take turns every > other month making the release on a set day, say the 15th > of the month or whatever. If anyone else wants to take a turn, > be my guest! I will make sure you have file release privileges. 15th sounds better than 13th! > In the end, this will be less work for us in 2 ways: (1) no > dreaded exhaustive rebuild on many systems that takes time. > (2) users who obtain the latest release instead of the cvs > will report fewer "previous version" bugs, and we will not > have to say "Check out the cvs version" until we go crazy. You are right with that. Are the examples considered to be sufficient to test the whole library? If there is a simple way to do the testing, everybody could help by just checking out the CVS and let the testsuite run (make runexamples). BTW: what is the test directory for? Martin |
From: John P. <pet...@cf...> - 2004-05-12 18:05:26
|
Martin L=FCthi writes: > John Peterson writes: > > It seems the toughest road-block to making a release > > is that someone (read Ben) has to download and build > > the library on N different platforms to make sure everything > > is still hunky-dory everywhere. > >=20 > > I would vote for a more active release schedule, say every > > month or 2 weeks, where we just release what we have without the > > exhaustive rebuild on every system. That way we let users > > who are actually on those systems discover the bugs ;) and > > report them, and then a new release is not far away. >=20 > +1 >=20 > > If everyone agrees, then I suggest Ben and I take turns every > > other month making the release on a set day, say the 15th > > of the month or whatever. If anyone else wants to take a turn, > > be my guest! I will make sure you have file release privileges. >=20 > 15th sounds better than 13th! >=20 > > In the end, this will be less work for us in 2 ways: (1) no > > dreaded exhaustive rebuild on many systems that takes time. > > (2) users who obtain the latest release instead of the cvs > > will report fewer "previous version" bugs, and we will not > > have to say "Check out the cvs version" until we go crazy. >=20 > You are right with that. Are the examples considered to be sufficien= t > to test the whole library? If there is a simple way to do the testin= g, > everybody could help by just checking out the CVS and let the > testsuite run (make runexamples). For now yes, see comment below... > BTW: what is the test directory for? Hopefully someday we will have regression tests, which are more like unit tests I suppose, and which, if passed, certify the library is "working". Right now the examples are filling in in that capacity, but we are not really *checking* the output in any way. In a regression test, you would make sure you can recover say O(h^{p+1}) dependence of the error in the Poisson problem for successively refined grids. -John |